Summary: | dev-libs/boost-1.49.0-r2: Segmentation fault during install phase. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Walther <walther.md> |
Component: | [OLD] Library | Assignee: | C++ Team [disbanded] <cpp+disabled> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Walther
2012-11-09 19:10:38 UTC
I'd say start by dropping -fno-var-tracking. Well, the manpage for gcc says that flag is for compilations which have debugging symbols enabled. I removed it and retried and... got the same segmentation fault. In fact, I decided to go ahead and use CFLAGS="-march=native -Os" I get the same segmentation fault: /var/tmp/portage/dev-libs/boost-1.49.0-r2/temp/environment : ligne 5225 : 26556 Erreur de segmentation ${BJAM} -q -d+2 gentoorelease --user-config=user-config.jam ${OPTIONS} threading=single,multi ${LINK_OPTS} runtime-link=shared --includedir="${D}usr/include" --libdir="${D}usr/$(get_libdir)" $(use python && echo --python-buildid=${PYTHON_ABI}) install Did you rebuild boost-build with those flags? Because that's the one that segfaults. I'd say the other thing is to find out where it segfaults: http://www.gentoo.org/proj/en/qa/backtraces.xml Okay, the links have helped me start debugging this. The problem seems to be triggered by having "low" memory (I have 4GB with no swap). The backtrace points to: CMD * cmd_new( RULE * rule, LIST * targets, LIST * sources, LIST * shell ) (boost_1_49_0/tools/build/v2/engine/command.c): if ( !no_limit ) { /* Bail if the result will not fit in MAXLINE. */ char * s = cmd->buf; while ( *s ) cmd->buf was previously null, so the "while" condition crashes. Right above that, the culprit is: BJAM_FREE( cmd->buf ); /* free any buffer from previous iteration */ cmd->buf = (char*)BJAM_MALLOC_ATOMIC( max_line + 1 ); if ( cmd->buf == 0 ) break; Which allows cmd->buf to be null. I added a print to check what max_line was, and it starts with the value of "#define MAXLINE 102400," explaining why I am running out of memory so quickly. Finally, I decided to change the code a bit, so that max_line starts with 1024 instead of MAXLINE: cmd->buf = (char*)BJAM_MALLOC_ATOMIC( max_line + 1 ); if ( cmd->buf == 0 ) { /* We do not free targets/sources/shell if bailing. */ printf("BAILED AFTER ALLOC-INT %d/%d\n", max_line+1, MAXLINE); cmd_free( cmd ); return 0; } However, this now causes a crash elsewhere which I can't understand: Core was generated by `b2-1_49 -q -d+2 gentoorelease --user-config=user-config.jam -sICU_PATH=/usr --w'. Program terminated with signal 11, Segmentation fault. #0 0xf7736cf1 in ?? () from /lib/libc.so.6 (gdb) bt #0 0xf7736cf1 in ?? () from /lib/libc.so.6 #1 0x080523f5 in newstr (string=<optimized out>) at /usr/include/bits/string3.h:52 #2 0x0804c548 in var_expand (l=0x0, in=0x5c6b05 "\"", end=0x5c6b06 "", lol=0x5c6aa0, cancopyin=0) at expand.c:477 #3 0x08055ff9 in var_string (in=0x8e2fa77 " $(WINDOWS-CP-HACK) \"$(<)\"\n", out=0x5c6b06 "", outsize=1024, lol=0x5c6aa0) at variable.c:325 #4 0x08049cb4 in cmd_new (rule=0x8e39560, targets=0x122878b0, sources=0x1228bc20, shell=0x0) at command.c:63 At this point, the code is more complex than I can understand, so I cannot be certain whether the crash is still induced due to low memory or it lies somewhere else. Though I'd prefer being able to compile boost without having to add swap... On the very least, if this is really a memory constrained situation, shouldn't the ebuild say something about it? 4GB has reasonably let me build everything out there (including libreoffice). (In reply to comment #4) I have 8GB RAM plus 1 GB swap, the install still hangs. By rebuilding boost-build and boot with CFLAGS="-march=native -O2" it worked in my case. What was suggested by Diego is correct. Usage of sane CFLAGS fixed the issue. Closing this as INVALID |