Date: Mon, 19 Aug 2002 13:20:41 -0400 (EDT) From: David Korn <dgk@research.att.com> To: joek@mail.flyingcroc.net Cc: gsf@research.att.com Subject: Re: Re: Bizarre ksh problem on FreeBSD Message-ID: <200208191720.NAA39626@raptor.research.att.com>
next in thread | raw e-mail | index | archive | help
> .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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208191720.NAA39626>