Bug 19983
| Summary: | sh dumps core reproducibly | ||
|---|---|---|---|
| Product: | Base System | Reporter: | pfeifer <pfeifer> |
| Component: | bin | Assignee: | tegge |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Iffy-looking How-To-Repeat. :-) Could you compile a debuggable sh binary and send a backtrace of the dump to <freebsd-gnats-submit@FreeBSD.ORG>, preserving this subject line? That should help the maintainer of the shell significantly. Responsible Changed From-To: freebsd-bugs->cracauer Over to the Bourne Identity. On Tue, 18 Jul 2000 sheldonh@freebsd.org wrote: > Could you compile a debuggable sh binary and send a backtrace of the > dump to <freebsd-gnats-submit@FreeBSD.ORG>, preserving this subject > line? > > That should help the maintainer of the shell significantly. Here we go! Fortunately, also the debug binary crashes. ;-) Program terminated with signal 11, Segmentation fault. #0 popstackmark (mark=0xbfbfd79c) at memalloc.c:191 191 stackp = sp->prev; (gdb) bt #0 popstackmark (mark=0xbfbfd79c) at memalloc.c:191 #1 0x804b9a7 in evalcommand (cmd=0x80a32d4, flags=0, backcmd=0x0) at eval.c:917 #2 0x804a8f9 in evaltree (n=0x80a32d4, flags=0) at eval.c:269 #3 0x804a863 in evaltree (n=0x80a32e4, flags=0) at eval.c:241 #4 0x804a772 in evaltree (n=0x80a332c, flags=0) at eval.c:203 #5 0x804a772 in evaltree (n=0x80a33b4, flags=0) at eval.c:203 #6 0x804a863 in evaltree (n=0x809e484, flags=0) at eval.c:241 #7 0x804a863 in evaltree (n=0x80a33c4, flags=0) at eval.c:241 #8 0x804a9ef in evalloop (n=0x809e3c0) at eval.c:317 #9 0x804a882 in evaltree (n=0x809e3c0, flags=1) at eval.c:248 #10 0x804ae21 in evalpipe (n=0x809e39c) at eval.c:511 #11 0x804a8ea in evaltree (n=0x809e39c, flags=0) at eval.c:266 #12 0x80517f3 in cmdloop (top=1) at main.c:253 #13 0x8051713 in main (argc=2, argv=0xbfbfd938) at main.c:202 #14 0x80480e9 in _start () I could reproduce the bug with a debug version of sh both on 3.4 and 4.0: Please note that nearly *any* change to the script makes the bug go away, even replacing `pwd` by some fixed path! Weird. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ Have a look at http://petition.eurolinux.org -- it's not about Linux, btw! Hi Martin, May I assign bin/19983 to Tor, who's come up with a patch, or would you still like to own this? I ask because I know that you've got very little time available for FreeBSD at the moment. Ciao, Sheldon. In <8616.965641328@axl.ops.uunet.co.za>, Sheldon Hearn wrote: > > May I assign bin/19983 to Tor, who's come up with a patch, or would you > still like to own this? I ask because I know that you've got very > little time available for FreeBSD at the moment. Actually, my timeconsumer ended with a full day of talking to very nice and brigth hackers a few thousand miles away last Friday :-) I'm cleaning up some things and will restart on my PRs soons. Having said this, I see no reason not to commit this particular patch and close the PR right now. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ State Changed From-To: feedback->open Feedback was sent but didn't seem to make it into the audit trail. Responsible Changed From-To: cracauer->tegge Tor has a patch that Martin is happy with. State Changed From-To: open->closed Fix in -current. Will be in 4-stable soon. |
I consistently get the following core dump from /bin/sh for the script listed under "How to repeat": sh in free(): warning: junk pointer, too low to make sense. Segmentation fault I tested this on two 4.0-RELEASE boxes. Another box, running 3.4-RELEASE aborts a bit differently. sh in free(): warning: junk pointer, too low to make sense. Oops, stackp deleted Abort trap How-To-Repeat: Run the script below in a large directory tree (which is not necessarily a CVS tree) like /usr/share. After about 12 directories the segmentation fault happens. Nearly any modification of this script -- even removing some parameters of the cvs command! -- makes the problem go away! ---- cut ---- #!/bin/sh find `pwd` -type d -exec echo {} \; | while read name; do dir=`dirname $name` if [ -d $dir ]; then echo "Updating $dir" visited="$visited:$dir" cd $dir cvs -q update -PAd -l fi done