From nobody@FreeBSD.org  Thu Feb  7 09:03:08 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
	by hub.freebsd.org (Postfix) with ESMTP id AB0666F7
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  7 Feb 2013 09:03:08 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 8F669EBF
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  7 Feb 2013 09:03:08 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r17938BC038524
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 7 Feb 2013 09:03:08 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id r17938QL038523;
	Thu, 7 Feb 2013 09:03:08 GMT
	(envelope-from nobody)
Message-Id: <201302070903.r17938QL038523@red.freebsd.org>
Date: Thu, 7 Feb 2013 09:03:08 GMT
From: "O. Hartmann" <ohartman@zedat.fu-berlin.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: security/libtasn1: Segmentation fault (sh coredumps at the end of the registering process)
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         175922
>Category:       bin
>Synopsis:       sh(1): segmentation fault while installing security/libtasn1
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jilles
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 07 09:10:00 UTC 2013
>Closed-Date:    Fri Mar 01 22:49:39 UTC 2013
>Last-Modified:  Fri Mar 01 22:49:39 UTC 2013
>Originator:     O. Hartmann
>Release:        FreeBSD 10-CURRENT/amd64
>Organization:
FU Berlin
>Environment:
1) FreeBSD 10.0-CURRENT #1 r246366: Tue Feb  5 17:14:19 CET 2013 amd64 (CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3300.09-MHz K8-class CPU))
2) FreeBSD 10.0-CURRENT #1 r246366: Tue Feb  5 17:14:19 CET 2013 amd64 (CPU: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz (2999.72-MHz K8-class CPU))
3) FreeBSD 10.0-CURRENT #1 r246435: Wed Feb  6 20:09:00 CET 2013 amd64 (CPU: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (3209.59-MHz K8-class CPU))
>Description:
Updating as requested in ports/UPDATING ends up in a corrupted update/installation: just before pkg(ng) is capable of updating the database, it seems, that the Bourne-shell (sh) is crashing - no matter why. The end is that the installation of port security/libtasn1 isn't reported installed anymore, but has been installed  so far. The coredump of the shell, sh.core, remains in the port's installation folder.


test -z "/usr/local/include" || ../build-aux/install-sh -c -d "/usr/local/include"
 install  -o root -g wheel -m 444 libtasn1.h '/usr/local/include'
test -z "/usr/local/libdata/pkgconfig" || ../build-aux/install-sh -c -d "/usr/local/libdata/pkgconfig"
 install  -o root -g wheel -m 444 libtasn1.pc '/usr/local/libdata/pkgconfig'
Making install in src
test -z "/usr/local/bin" || ../build-aux/install-sh -c -d "/usr/local/bin"
  /bin/sh ../libtool   --mode=install install  -s -o root -g wheel -m 555 asn1Parser asn1Coding asn1Decoding '/usr/local/bin'
libtool: install: install -o root -g wheel -m 555 -s .libs/asn1Parser /usr/local/bin/asn1Parser
libtool: install: install -o root -g wheel -m 555 -s .libs/asn1Coding /usr/local/bin/asn1Coding
libtool: install: install -o root -g wheel -m 555 -s .libs/asn1Decoding /usr/local/bin/asn1Decoding
Making install in examples
/usr/bin/make  install-am
Making install in tests
Making install in doc
Making install in cyclo
test -z "/usr/local/info" || ../build-aux/install-sh -c -d "/usr/local/info"
 install  -o root -g wheel -m 444 ./libtasn1.info '/usr/local/info'
 install-info --info-dir='/usr/local/info' '/usr/local/info/libtasn1.info'
test -z "/usr/local/man/man1" || ../build-aux/install-sh -c -d "/usr/local/man/man1"
 install  -o root -g wheel -m 444 asn1Parser.1 asn1Coding.1 asn1Decoding.1 '/usr/local/man/man1'
test -z "/usr/local/man/man3" || ../build-aux/install-sh -c -d "/usr/local/man/man3"
Segmentation fault
*** [install-man3] Error code 139

Stop in /usr/ports/security/libtasn1/work/libtasn1-2.14/doc.
*** [install-am] Error code 1

Stop in /usr/ports/security/libtasn1/work/libtasn1-2.14/doc.
*** [install-recursive] Error code 1

Stop in /usr/ports/security/libtasn1/work/libtasn1-2.14/doc.
*** [install-recursive] Error code 1

Stop in /usr/ports/security/libtasn1/work/libtasn1-2.14.
*** [do-install] Error code 1

Stop in /usr/ports/security/libtasn1.

===>>> Installation of libtasn1-2.14 (security/libtasn1) failed
===>>> Aborting update

>How-To-Repeat:
Install or update, as requested, port security/libtasn1 on FreeBSD 10-CURRENT/amd64 (clang buildworld).

This problem occurs obviously on all FreeBSD 10.0-CURRENT installations and seems not to be present on 9.1-STABLE (from the first attempt to update). 
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->novel 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Thu Feb 7 09:10:07 UTC 2013 
Responsible-Changed-Why:  
Over to maintainer (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=175922 

From: KT Sin <ktsin@acm.org>
To: bug-followup@FreeBSD.org, ohartman@zedat.fu-berlin.de
Cc: jilles@freebsd.org
Subject: Re: ports/175922: security/libtasn1: Segmentation fault (sh coredumps at the end of the registering process)
Date: Sat, 9 Feb 2013 19:29:51 -0800 (PST)

 i'm getting the same problem when installing devel/pcre from ports. turning on the debugging mode reveals that there's issue with popstackmark in evaltree() in /bin/sh.
 
 adding jilles@ to the loop hoping that he can help to solve the problem.
 
 $ gdb /bin/sh sh.core 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "amd64-marcel-freebsd"...
 Core was generated by `sh'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /lib/libedit.so.7...done.
 Loaded symbols for /lib/libedit.so.7
 Reading symbols from /lib/libncurses.so.8...done.
 Loaded symbols for /lib/libncurses.so.8
 Reading symbols from /lib/libc.so.7...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 203	memalloc.c: No such file or directory.
 	in memalloc.c
 (gdb) bt
 #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 #1  0x0000000000405ada in evaltree (n=<value optimized out>, flags=0)
     at eval.c:298
 #2  0x000000000040572d in evaltree (n=<value optimized out>, flags=0)
     at eval.c:338
 #3  0x00000000004054fc in evaltree (n=<value optimized out>, flags=1)
     at eval.c:214
 #4  0x00000000004058e4 in evaltree (n=<value optimized out>, flags=1)
     at eval.c:606
 #5  0x00000000004053f0 in evalstring (s=<value optimized out>, 
     flags=<value optimized out>) at eval.c:173
 #6  0x0000000000410495 in main (argc=<value optimized out>, 
     argv=<value optimized out>) at main.c:171
 Current language:  auto; currently minimal
 (gdb) bt full
 #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 	sp = (struct stack_block *) 0x0
 #1  0x0000000000405ada in evaltree (n=<value optimized out>, flags=0)
     at eval.c:298
 	smark = {stackp = 0x81884a00, 
   stacknxt = 0x81884a08 'Z' <repeats 200 times>..., stacknleft = 504, 
   marknext = 0x7fffffffcf38}
 	do_etest = Cannot access memory at address 0x0
 (gdb) 
 

From: Jilles Tjoelker <jilles@stack.nl>
To: KT Sin <ktsin@acm.org>
Cc: bug-followup@FreeBSD.org, ohartman@zedat.fu-berlin.de
Subject: Re: ports/175922: security/libtasn1: Segmentation fault (sh
 coredumps at the end of the registering process)
Date: Sun, 10 Feb 2013 17:48:55 +0100

 On Sat, Feb 09, 2013 at 07:29:51PM -0800, KT Sin wrote:
 > i'm getting the same problem when installing devel/pcre from ports.
 > turning on the debugging mode reveals that there's issue with
 > popstackmark in evaltree() in /bin/sh.
 
 > adding jilles@ to the loop hoping that he can help to solve the problem.
 
 > $ gdb /bin/sh sh.core 
 > GNU gdb 6.1.1 [FreeBSD]
 > Copyright 2004 Free Software Foundation, Inc.
 > GDB is free software, covered by the GNU General Public License, and you are
 > welcome to change it and/or distribute copies of it under certain conditions.
 > Type "show copying" to see the conditions.
 > There is absolutely no warranty for GDB.  Type "show warranty" for details.
 > This GDB was configured as "amd64-marcel-freebsd"...
 > Core was generated by `sh'.
 > Program terminated with signal 11, Segmentation fault.
 > Reading symbols from /lib/libedit.so.7...done.
 > Loaded symbols for /lib/libedit.so.7
 > Reading symbols from /lib/libncurses.so.8...done.
 > Loaded symbols for /lib/libncurses.so.8
 > Reading symbols from /lib/libc.so.7...done.
 > Loaded symbols for /lib/libc.so.7
 > Reading symbols from /libexec/ld-elf.so.1...done.
 > Loaded symbols for /libexec/ld-elf.so.1
 > #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 > 203	memalloc.c: No such file or directory.
 > 	in memalloc.c
 > (gdb) bt
 > #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 > #1  0x0000000000405ada in evaltree (n=<value optimized out>, flags=0)
 >     at eval.c:298
 > #2  0x000000000040572d in evaltree (n=<value optimized out>, flags=0)
 >     at eval.c:338
 > #3  0x00000000004054fc in evaltree (n=<value optimized out>, flags=1)
 >     at eval.c:214
 > #4  0x00000000004058e4 in evaltree (n=<value optimized out>, flags=1)
 >     at eval.c:606
 > #5  0x00000000004053f0 in evalstring (s=<value optimized out>, 
 >     flags=<value optimized out>) at eval.c:173
 > #6  0x0000000000410495 in main (argc=<value optimized out>, 
 >     argv=<value optimized out>) at main.c:171
 > Current language:  auto; currently minimal
 > (gdb) bt full
 > #0  popstackmark (mark=0x7fffffffcea8) at memalloc.c:203
 > 	sp = (struct stack_block *) 0x0
 > #1  0x0000000000405ada in evaltree (n=<value optimized out>, flags=0)
 >     at eval.c:298
 > 	smark = {stackp = 0x81884a00, 
 >   stacknxt = 0x81884a08 'Z' <repeats 200 times>..., stacknleft = 504, 
 >   marknext = 0x7fffffffcf38}
 > 	do_etest = Cannot access memory at address 0x0
 > (gdb) 
 
 I cannot reproduce this locally and unfortunately the stack trace does
 not contain the command line that caused it to crash.
 
 Some very old commit logs hint at problems with calling popstackmark()
 multiple times for the same stack mark. The below patch would fix that:
 
 Index: bin/sh/eval.c
 ===================================================================
 --- bin/sh/eval.c	(revision 246301)
 +++ bin/sh/eval.c	(working copy)
 @@ -174,6 +174,7 @@ evalstring(char *s, int flags)
  			any = 1;
  		}
  		popstackmark(&smark);
 +		setstackmark(&smark);
  	}
  	popfile();
  	popstackmark(&smark);
 @@ -296,6 +297,7 @@ evaltree(union node *n, int flags)
  		}
  		n = next;
  		popstackmark(&smark);
 +		setstackmark(&smark);
  	} while (n != NULL);
  out:
  	popstackmark(&smark);
 
 Alternatively, you can try to revert r245698 or revert sh to r245697.
 
 I would like to have a test case for this bug, though, so I can add it
 to tools/regression/bin/sh and stop the bug coming back.
 
 -- 
 Jilles Tjoelker

From: KT Sin <ktsin@acm.org>
To: Jilles Tjoelker <jilles@stack.nl>, bug-followup@FreeBSD.org
Cc: ohartman@zedat.fu-berlin.de
Subject: Re: ports/175922: security/libtasn1: Segmentation fault (sh coredumps at the end of the registering process)
Date: Wed, 13 Feb 2013 19:45:04 -0800 (PST)

 --1458549034-643941739-1360813504=:92852
 Content-Type: text/plain; charset=us-ascii
 
 adding setstackmark() in evaltree() does fix the problem for me. however, i do not have any simpler or neater test case for regression. the test case i used was lifted from the install code in makefile. see the attached file.
 
 after enabling debugging and tracing, it appears that when sh runs a child sub-process to handle a long and complicated pipe command (pid 1965 in my case), the child crashes with seg fault. you are correct, as the child process probably enters the do loop in evaltree(), and calling popstackmark() many times without calling setstackmark().
 
 passion:~[591]$ ./sh < test.in
  ./install-sh -c -d '/usr/local/man/man3'
 Segmentation fault (core dumped)
 passion:~[592]$ ls -l sh.core*
 -rw-------  1 ktsin  staff  8880128 Feb 14 11:23 sh.core.1965
 passion:~[593]$ grep 'In parent shell:' trace
 In parent shell:  child = 1958
 In parent shell:  child = 1959, cmd = for i in ...; if test -n ${list2}; then for j in ... | sed -n /\.3[a-z]*$/p...
 In parent shell:  child = 1960, cmd = while read p; do if test -f ${p}; then d=...; echo ${d}${p}; echo ${p}; done
 In parent shell:  child = 1961, cmd = for j in ...
 In parent shell:  child = 1962, cmd = sed -e n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$,3,;x -e s,\.[0-9a-z]*$,,;s,x,x,;G;s,\n,.,
 In parent shell:  child = 1963, cmd = sed N;N;s,\n, ,g
 In parent shell:  child = 1964, cmd = sed -n /\.3[a-z]*$/p
 In parent shell:  child = 1965, cmd = list=; while read file base inst; do if test ${base} = ${inst}; then list=${list} ${file}...; done; for i in ... | sed $!N;$!N;$!N;$!N;$!N;$!N;$!N;s/\n/ /g | sed $!N;$!N;$!N;$!N;s/\n/ /g | while r...
 
 thanks
 kit
 --1458549034-643941739-1360813504=:92852
 Content-Type: application/octet-stream; name="test.in"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="test.in"
 
 bGlzdD0nJyA7XApsaXN0Mj0nZG9jL3BjcmUxNi4zIGRvYy9wY3JlMTYuMyBk
 b2MvcGNyZTE2LjMgZG9jL3BjcmUxNi4zIGRvYy9wY3JlMTYuMyBkb2MvcGNy
 ZTE2LjMgZG9jL3BjcmUxNi4zIGRvYy9wY3JlMTYuMyBkb2MvcGNyZTE2LjMg
 ZG9jL3BjcmUuMyAgZG9jL3BjcmUxNi4zICBkb2MvcGNyZTMyLjMgIGRvYy9w
 Y3JlLWNvbmZpZy4xICBkb2MvcGNyZV9hc3NpZ25faml0X3N0YWNrLjMgIGRv
 Yy9wY3JlX2NvbXBpbGUuMyAgZG9jL3BjcmVfY29tcGlsZTIuMyAgZG9jL3Bj
 cmVfY29uZmlnLjMgIGRvYy9wY3JlX2NvcHlfbmFtZWRfc3Vic3RyaW5nLjMg
 IGRvYy9wY3JlX2NvcHlfc3Vic3RyaW5nLjMgIGRvYy9wY3JlX2RmYV9leGVj
 LjMgIGRvYy9wY3JlX2V4ZWMuMyAgZG9jL3BjcmVfZnJlZV9zdHVkeS4zICBk
 b2MvcGNyZV9mcmVlX3N1YnN0cmluZy4zICBkb2MvcGNyZV9mcmVlX3N1YnN0
 cmluZ19saXN0LjMgIGRvYy9wY3JlX2Z1bGxpbmZvLjMgIGRvYy9wY3JlX2dl
 dF9uYW1lZF9zdWJzdHJpbmcuMyAgZG9jL3BjcmVfZ2V0X3N0cmluZ251bWJl
 ci4zICBkb2MvcGNyZV9nZXRfc3RyaW5ndGFibGVfZW50cmllcy4zICBkb2Mv
 cGNyZV9nZXRfc3Vic3RyaW5nLjMgIGRvYy9wY3JlX2dldF9zdWJzdHJpbmdf
 bGlzdC4zICBkb2MvcGNyZV9qaXRfZXhlYy4zICBkb2MvcGNyZV9qaXRfc3Rh
 Y2tfYWxsb2MuMyAgZG9jL3BjcmVfaml0X3N0YWNrX2ZyZWUuMyAgZG9jL3Bj
 cmVfbWFrZXRhYmxlcy4zICBkb2MvcGNyZV9wYXR0ZXJuX3RvX2hvc3RfYnl0
 ZV9vcmRlci4zICBkb2MvcGNyZV9yZWZjb3VudC4zICBkb2MvcGNyZV9zdHVk
 eS4zICBkb2MvcGNyZV91dGYxNl90b19ob3N0X2J5dGVfb3JkZXIuMyAgZG9j
 L3BjcmVfdXRmMzJfdG9faG9zdF9ieXRlX29yZGVyLjMgIGRvYy9wY3JlX3Zl
 cnNpb24uMyAgZG9jL3BjcmVhcGkuMyAgZG9jL3BjcmVidWlsZC4zICBkb2Mv
 cGNyZWNhbGxvdXQuMyAgZG9jL3BjcmVjb21wYXQuMyAgZG9jL3BjcmVncmVw
 LjEgIGRvYy9wY3Jlaml0LjMgIGRvYy9wY3JlbGltaXRzLjMgIGRvYy9wY3Jl
 bWF0Y2hpbmcuMyAgZG9jL3BjcmVwYXJ0aWFsLjMgIGRvYy9wY3JlcGF0dGVy
 bi4zICBkb2MvcGNyZXBlcmZvcm0uMyAgZG9jL3BjcmVwb3NpeC4zICBkb2Mv
 cGNyZXByZWNvbXBpbGUuMyAgZG9jL3BjcmVzYW1wbGUuMyAgZG9jL3BjcmVz
 dGFjay4zICBkb2MvcGNyZXN5bnRheC4zICBkb2MvcGNyZXRlc3QuMSAgZG9j
 L3BjcmV1bmljb2RlLjMgZG9jL3BjcmVjcHAuMyc7IFwKdGVzdCAtbiAiL3Vz
 ci9sb2NhbC9tYW4vbWFuMyIgICYmIHRlc3QgLW4gImBlY2hvICRsaXN0MSRs
 aXN0MmAiICB8fCBleGl0IDA7IFwKZWNobyAiIC4vaW5zdGFsbC1zaCAtYyAt
 ZCAnL3Vzci9sb2NhbC9tYW4vbWFuMyciOyBcCi4vaW5zdGFsbC1zaCAtYyAt
 ZCAiL3Vzci9sb2NhbC9tYW4vbWFuMyIgfHwgZXhpdCAxOyBcCnsgZm9yIGkg
 aW4gJGxpc3QxOyBkbyBlY2hvICIkaSI7IGRvbmU7ICAgaWYgdGVzdCAtbiAi
 JGxpc3QyIjsgdGhlbiAgZm9yIGogaW4gJGxpc3QyOyBkbyBlY2hvICIkaiI7
 IGRvbmUgIHwgc2VkIC1uICcvXC4zW2Etel0qJC9wJzsgIGZpOyAgfSB8IHdo
 aWxlIHJlYWQgcDsgZG8gIGlmIHRlc3QgLWYgJHA7IHRoZW4gZD07IGVsc2Ug
 ZD0iLi8iOyBmaTsgIGVjaG8gIiRkJHAiOyBlY2hvICIkcCI7ICBkb25lIHwg
 IHNlZCAtZSAnbjtzLC4qLywsO3A7aDtzLC4qXC4sLDtzLF5bXjNdWzAtOWEt
 el0qJCwzLDt4JyAgLWUgJ3MsXC5bMC05YS16XSokLCw7cyx4LHgsO0c7cyxc
 biwuLCcgfCAgc2VkICdOO047cyxcbiwgLGcnIHwgeyAgbGlzdD07IHdoaWxl
 IHJlYWQgZmlsZSBiYXNlIGluc3Q7IGRvICBpZiB0ZXN0ICIkYmFzZSIgPSAi
 JGluc3QiOyB0aGVuIGxpc3Q9IiRsaXN0ICRmaWxlIjsgZWxzZSAgZWNobyAi
 IGluc3RhbGwgICAtbSA0NDQgJyRmaWxlJyAnL3Vzci9sb2NhbC9tYW4vbWFu
 My8kaW5zdCciOyAgaW5zdGFsbCAgIC1tIDQ0NCAiJGZpbGUiICIvdXNyL2xv
 Y2FsL21hbi9tYW4zLyRpbnN0IiB8fCBleGl0ICQ/OyAgZmk7ICBkb25lOyAg
 Zm9yIGkgaW4gJGxpc3Q7IGRvIGVjaG8gIiRpIjsgZG9uZSB8IHNlZCAnJCFO
 OyQhTjskIU47JCFOOyQhTjskIU47JCFOO3MvXG4vIC9nJyB8ICBzZWQgJyQh
 TjskIU47JCFOOyQhTjtzL1xuLyAvZycgfCAgd2hpbGUgcmVhZCBmaWxlczsg
 ZG8gIHRlc3QgLXogIiRmaWxlcyIgfHwgeyAgZWNobyAiIGluc3RhbGwgICAt
 bSA0NDQgJGZpbGVzICcvdXNyL2xvY2FsL21hbi9tYW4zJyI7ICBpbnN0YWxs
 ICAgLW0gNDQ0ICRmaWxlcyAiL3Vzci9sb2NhbC9tYW4vbWFuMyIgfHwgZXhp
 dCAkPzsgfTsgIGRvbmU7IH0K
 
 --1458549034-643941739-1360813504=:92852--

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/175922: commit references a PR
Date: Tue, 19 Feb 2013 23:46:59 +0000 (UTC)

 Author: jilles
 Date: Tue Feb 19 23:46:51 2013
 New Revision: 247013
 URL: http://svnweb.freebsd.org/changeset/base/247013
 
 Log:
   sh: Fix a crash with the stackmark code.
   
   If a stack mark is set while the current stack block is empty, the stack
   block may move later on (because of realloc()) and the stack mark needs to
   be updated. This updating does not happen after popstackmark() has been
   called; therefore, call setstackmark() again if the stack mark is still
   being used.
   
   For some reason, this only affects a few users. I cannot reproduce it. The
   situation seems quite rare as well because an empty stack block would
   usually be freed (by popstackmark()) before execution reaches a
   setstackmark() call.
   
   PR:		175922
   Tested by:	KT Sin
 
 Modified:
   head/bin/sh/eval.c
 
 Modified: head/bin/sh/eval.c
 ==============================================================================
 --- head/bin/sh/eval.c	Tue Feb 19 21:35:17 2013	(r247012)
 +++ head/bin/sh/eval.c	Tue Feb 19 23:46:51 2013	(r247013)
 @@ -174,6 +174,7 @@ evalstring(char *s, int flags)
  			any = 1;
  		}
  		popstackmark(&smark);
 +		setstackmark(&smark);
  	}
  	popfile();
  	popstackmark(&smark);
 @@ -296,6 +297,7 @@ evaltree(union node *n, int flags)
  		}
  		n = next;
  		popstackmark(&smark);
 +		setstackmark(&smark);
  	} while (n != NULL);
  out:
  	popstackmark(&smark);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: jilles 
State-Changed-When: Tue Feb 26 21:44:59 UTC 2013 
State-Changed-Why:  
I committed a likely fix in r247013, confirmed working by one user 
with a similar issue. 


Responsible-Changed-From-To: novel->jilles 
Responsible-Changed-By: jilles 
Responsible-Changed-When: Tue Feb 26 21:44:59 UTC 2013 
Responsible-Changed-Why:  
This appears to be a bug in sh and not a problem in a port. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=175922 
State-Changed-From-To: patched->closed 
State-Changed-By: jilles 
State-Changed-When: Fri Mar 1 22:48:47 UTC 2013 
State-Changed-Why:  
The submitter has confirmed that the change fixes the problem. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=175922 
>Unformatted:
