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