[jamming] Segfault w/ GCC 4.2

[Ingo Weinhold]

On 2007-05-14 at 05:53:15 [+0200], Ryan Hill <dirtyepic at gentoo.org> wrote:
> Building jam-2.5 with GCC 4.2 is causing a segfault when jam0 is run.
> 
> Compiling source in/var/tmp/portage/dev-util/jam-2.5-r3/work/jam-2.5 ...
> 
> cc -o ./jam0 -O2 -g -march=prescott -fomit-frame-pointer -fno-ident
> -pipe builtins.c command.c compile.c execunix.c execvms.c expand.c
> filent.c fileos2.c fileunix.c filevms.c glob.c hash.c headers.c jam.c
> jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c
> pathunix.c pathvms.c regexp.c rules.c scan.c search.c timestamp.c variable.c
> execunix.c: In function 'execcmd':
> execunix.c:235: warning: incompatible implicit declaration of built-in
> function '_exit'
> ./jam0
> make: *** [all] Segmentation fault
> 
> root at tycho ~/portage/dev-util/jam-2.5-r3/work/jam-2.5 # ./jam0
> Segmentation fault
> GNU gdb 6.6
> Copyright (C) 2006 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 "i686-pc-linux-gnu".
> (gdb) file jam0
> Reading symbols from
> /var/tmp/portage/dev-util/jam-2.5-r3/work/jam-2.5/jam0...done.
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) run
> Starting program: /var/tmp/portage/dev-util/jam-2.5-r3/work/jam-2.5/jam0
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804bf3d in hashitem (hp=0x805f2e0, data=0xbffb2588, enter=1) at
> hash.c:108
> 108 keyval = *b;
> (gdb) bt
> #0 0x0804bf3d in hashitem (hp=0x805f2e0, data=0xbffb2588, enter=1) at
> hash.c:108
> #1 0x0804f279 in newstr (string=0x50891424 <Address 0x50891424 out of
> bounds>) at newstr.c:52
> #2 0x08050a41 in addsettings (head=0x0, setflag=0, symbol=0x50891424
> <Address 0x50891424 out of bounds>, value=0x80a4168) at rules.c:253
> #3 0x0804a08a in evaluate_rule (rulename=0x8060520 "Depends",
> args=0xbffb2614, result=0x0) at compile.c:586

The code there (ll. 585-587) reads:

	    for( l = rule->params, i = 0; l; l = l->next, i++ )
		s = addsettings( s, 0, l->string, 
		    list_copy( L0, lol_get( args, i ) ) );

Apparently a string pointer in the rule's parameter list is invalid. The list 
is built in compile_setcomp() (which looks OK to me) and AFAIK is never 
changed afterwards.

Given that gcc 4.2 is not yet released yet, I wouldn't rule out that a gcc 
regression is responsible.

CU, Ingo

PS: Out of curiosity, how do you auto-attach a gdb to a crashed program?