Attachment 24416 Details for Bug 41778 – path.c.diff

[patch] path.c.diff

path.c.diff (text/plain), 8.55 KB, created by Joe Kelsey on 2002-08-19 19:40:34 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Joe Kelsey

Created: 2002-08-19 19:40:34 UTC

Size: 8.55 KB

patch

obsolete

>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 <joek@mail.flyingcroc.net>; 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 <joek@mail.flyingcroc.net>; 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 <dgk@research.att.com>
>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
>

Actions: View | Diff

Attachments on bug 41778: 24415 | 24416