Re: [boost] bjam crashes when compile with gcc 4.2.0

From: Martin Wille (mw8329_at_[hidden])
Date: 2007-05-23 11:19:46

Rene Rivera wrote:
> Ismail Dönmez wrote:
>> Hi all,
>>
>> bjam crashes when compiled with gcc 4.2.0, simply running it will result in a 
>> crash:
>>
>> southpark boost_1_34_0 # ./tools/jam/src/bin.linuxx86/bjam 
>> zsh: segmentation fault
>>
>> Looks like a similar bug is reported a year ago to Debian bugzilla [1] [2] . 
>> Since gcc 4.2.0 is now a released compiler, imho the issue is now more 
>> important.
>>
>> Any ideas appreciated.
>>
>> [0] http://svn.boost.org/trac/boost/ticket/977
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367825
>> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372470
> 
> Hm, I've been running bjam 3.1.15 with gcc 4.2 repeatedly yesterday and 
> today in Ubuntu. So something is messed up with the 3.1.14 version, and 
> hopefully it's not a Debian only problem.

It's not. I can reproduce the same problem on Gentoo with vanilla gcc 4.2.0

Additional information:

The bjam executable works if built with --debug

strace indicates that bjam crashes even before it starts searching for
configuration files:

fstat(3, {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0
mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaaaaae1000
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0"...,
131072) = 2295
close(3)
munmap(0x2aaaaaae1000, 131072)          = 0
uname({sys="Linux", node="DonQuixote", ...}) = 0

<-- Crash here if not built with --debug -->

brk(0x572000)                           = 0x572000
brk(0x593000)                           = 0x593000
brk(0x5b4000)                           = 0x5b4000
brk(0x5d5000)                           = 0x5d5000
brk(0x5f7000)                           = 0x5f7000
brk(0x618000)                           = 0x618000
stat("/usr/share/boost-build", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
open("/usr/share/boost-build", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3

ltrace output might also be helpful:

strlen("rules")
         = 5
memcpy(0x52a8b4, "rules", 6)
         = 0x52a8b4
malloc(584)
         = 0x533fb0
malloc(880)
         = 0x534200
malloc(264)
         = 0x534580
memset(0x534580, '\000', 264)
         = 0x534580
memcpy(0x534210, "\027\322A", 48)
         = 0x534210
memcpy(0x52ee18, "\027\322A", 8)
         = 0x52ee18
strlen("ALWAYS")
         = 6
memcpy(0x52a8ba, "ALWAYS", 7)
         = 0x52a8ba

<-- Crash here if not built with --debug -->

memcpy(0x53b2d0, "'3B", 48)                      = 0x53b2d0
memcpy(0x535e30, "'3B", 8)                       = 0x535e30
strlen("Always")                                 = 6
memcpy(0x531204, "Always", 7)                    = 0x531204
malloc(80)                                       = 0x53b700
memcpy(0x53b320, ".3B", 48)                      = 0x53b320
memcpy(0x535e48, ".3B", 8)                       = 0x535e48
strlen("DEPENDS")                                = 7
memcpy(0x53120b, "DEPENDS", 8)                   = 0x53120b
memcpy(0x53b370, "63B", 48)                      = 0x53b370
memcpy(0x535e60, "63B", 8)                       = 0x535e60
strlen("Depends")                                = 7
memcpy(0x531213, "Depends", 8)                   = 0x531213
malloc(80)                                       = 0x53b760
memcpy(0x53b3c0, ">3B", 48)                      = 0x53b3c0
memcpy(0x535e78, ">3B", 8)                       = 0x535e78
strlen("ECHO")                                   = 4
memcpy(0x53121b, "ECHO", 5)                      = 0x53121b
memcpy(0x53b410, "C3B", 48)                      = 0x53b410
memcpy(0x535e90, "C3B", 8)                       = 0x535e90

(A whole lotta memcopying going on, btw)

This seems to indicate a problem around load_builtins() in builtins.c

HTH,
m