From - Mon Aug 19 10:44:58 2002 X-UIDL: 6c581aecb454d2b2e24d8960d66a1521 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: dgk@research.att.com Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id KAA75058 for ; Mon, 19 Aug 2002 10:21:13 -0700 (PDT) Received: from raptor.research.att.com (raptor.research.att.com [135.207.23.32]) by mail-green.research.att.com (Postfix) with ESMTP id 01FBF1E14E for ; Mon, 19 Aug 2002 13:20:41 -0400 (EDT) Received: (from dgk@localhost) by raptor.research.att.com (SGI-8.9.3/8.8.7) id NAA39626; Mon, 19 Aug 2002 13:20:41 -0400 (EDT) Date: Mon, 19 Aug 2002 13:20:41 -0400 (EDT) From: David Korn Message-Id: <200208191720.NAA39626@raptor.research.att.com> X-Mailer: mailx (AT&T/BSD) 9.9 2002-05-31 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joek@mail.flyingcroc.net Subject: Re: Re: Bizarre ksh problem on FreeBSD Cc: gsf@research.att.com X-UIDL: 6c581aecb454d2b2e24d8960d66a1521 Status: U > .As far as I can tell, this is a bug in the stak library and/or the sfio > .library. It appears that the 'stakputc' call in path_addcomp is coming > .up against an off-by-one error. I changed the use of 'stakputc' to > .'stakwrite' to solve the problem. Karsten Fleischer reports that he got > .word from dgk that he was fixing this bug. It would be nice to have a > .heads-up about it. > . > .Attached is my diff to src/cmd/ksh93/sh/path.c. > . > ./Joe > . > .Joe Kelsey wrote: > . > .> OK, I have a very puzzling ksh problem on FreeBSD. The command > .> > .> ksh -c 'grep stdio */*' > .> > .> dumps core! I have traced it through various areas and I think it is > .> some undesirable interaction between glob and stak. The glob seems to > .> work correctly, finding all 194 files, but when the shell calls > .> path_search to find grep, something very strange happens in > .> path_addcomp. The stakputc("/.paths"); near the beginning of > .> path_addcomp overwrites the name value. On entry to path_addcomp, > .> name="/usr/bin:/bin:/usr/local/bin", but as soon as the stackputc > .> runs, it is magically transformed into "/usr/bin/.paths", straight up > .> the stack! > .> > .> Here is a backtrace before and after: > .> before > .> Breakpoint 6, path_addcomp (first=0x0, old=0x0, > .> name=0x816db30 "/usr/bin:/bin:/usr/sbin:/sbin:", flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:943 > .> (gdb) print cp > .> $44 = 0x816db30 "/usr/bin:/bin:/usr/sbin:/sbin:" > .> (gdb) bt > .> #0 path_addcomp (first=0x0, old=0x0, > .> name=0x816db30 "/usr/bin:/bin:/usr/sbin:/sbin:", flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:949 > .> #1 0x80637fe in path_addpath (first=0x0, > .> path=0x816db30 "/usr/bin:/bin:/usr/sbin:/sbin:", type=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:1105 > .> #2 0x80620ab in path_init (shp=0x812b940) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:234 > .> #3 0x80623cb in path_search (name=0x8160011 "grep", endpath=0x0, flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:368 > .> #4 0x8066d96 in sh_exec (t=0x8160018, flags=5) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/xec.c:488 > .> #5 0x8048f3d in exfile (iop=0x815e700, fno=-1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/main.c:520 > .> #6 0x80488fb in sh_main (ac=3, av=0xbfbff880, userinit=0) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/main.c:318 > .> #7 0x80481e8 in main (argc=3, argv=0xbfbff880) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/pmain.c:33 > .> #8 0x8048135 in _start () > .> > .> Then, after the stackputc(0): > .> #0 path_addcomp (first=0x0, old=0x0, name=0x816db30 "/usr/bin", flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:951 > .> #1 0x80637fe in path_addpath (first=0x0, path=0x816db30 "/usr/bin", > .> type=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:1105 > .> #2 0x80620ab in path_init (shp=0x812b940) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:234 > .> #3 0x80623cb in path_search (name=0x8160011 "grep", endpath=0x0, flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:368 > .> #4 0x8066d96 in sh_exec (t=0x8160018, flags=5) > .> at /usr/ports/shells/ksh93/work/srcprint /cmd/ksh93/sh/xec.c:488 > .> #5 0x8048f3d in exfile (iop=0x815e700, fno=-1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/main.c:520 > .> #6 0x80488fb in sh_main (ac=3, av=0xbfbff880, userinit=0) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/main.c:318 > .> #7 0x80481e8 in main (argc=3, argv=0xbfbff880) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/pmain.c:33 > .> #8 0x8048135 in _start () > .> > .> This seems to indicate that the stak functions are suddenly operating > .> on name instead of some temproary area? I do not understand the stak > .> part of ast... > .> > .> In any case, the ultimate result of all of this is a SEGFAULT caused > .> by appending ".paths" repeatedly to the string until memory is exhausted. > .> > .> Program received signal SIGSEGV, Segmentation fault. > .> 0x8063229 in path_addcomp (first=0x8166280, old=0x0, > .> name=0x816db39 > .> ".paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.paths.p"..., > .> flag=1) > .> at /usr/ports/shells/ksh93/work/src/cmd/ksh93/sh/path.c:948 > .> > .> Is there some sort of memory leak in glob which gets carried over? Is > .> glob not dealing with the stak functions correctly? I don't know > .> enough about the inner workings of ksh and ast to do more than a > .> superficial look at this. If anyone knows what I should do to debug > .> it further, I would really appreciate the advice. I am tired of > .> cleaning up all the ksh93.core files that are littered around my > .> system... > .> > .> /Joe > .> > .> > .> ____________________________________________________________ > .> If you need help unsubscribing or using this list in > .> general, send mail to owner-ast-users@research.att.com > .> To unsubscribe from this list, please send the following > .> two-line message to majordomo@research.att.com, in which > .> your_email_address should be replaced by the address you > .> used when you subscribed to the list: > .> unsubscribe ast-users your_email_address > .> end > .> > .> > . > . > . > .--- path.c.orig Mon Mar 11 10:50:16 2002 > .+++ path.c Mon Aug 19 07:07:04 2002 > .@@ -945,7 +945,8 @@ > . { > . register const char *cp = name; > . while(*cp && *cp!=':') > .- stakputc(*cp++); > .+ cp++; > .+ stakwrite(name,cp-name); > . len = staktell()-offset; > . stakputc(0); > . } > . Thanks, I think that I might understand the problem and if I do then your fix is not correct. The way path_addpath() is written, it assumes that none of the callers invoke it with strings that are on the stack. However, I think that the library routine astconf() is returning a string on the stack when looking up the default PATH. The add_pathcomp() function uses the stack by appending to it. Since the top element is not frozen, this allows it to be relocated if the stack reaches the end of a frame. I beleive that the correct solution is to freeze the stack at the beginning of path_add() so that it can accept arguments that are on the stack. I have included a context diff foir the changes. Could you please try them out and see whether this solves the problem. I wasn't able to reproduce the problem. =====================cut here======================== *** sh/path.c.old Fri Jul 26 16:40:06 2002 --- sh/path.c Mon Aug 19 13:17:10 2002 *************** *** 1058,1063 **** --- 1058,1066 ---- { register const char *cp; Pathcomp_t *old=0; + int offset = staktell(); + char *savptr; + if(!path && type!=PATH_PATH) return(first); if(type!=PATH_FPATH) *************** *** 1065,1070 **** --- 1068,1075 ---- old = first; first = 0; } + if(offset) + savptr = stakfreeze(0); if(path) while(*(cp=path)) { if(*cp==':') *************** *** 1094,1099 **** --- 1099,1108 ---- first = (void*)path_addpath((Pathcomp_t*)first,cp,PATH_FPATH); path_delete(old); } + if(offset) + stakset(savptr,offset); + else + stakseek(0); return(first); } =====================cut here======================== David Korn research!dgk dgk@research.att.com --------------070803080108070209000104-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message