[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 Georg Koppen changed: What|Removed |Added CC||gk at torproject dot org --- Comment #13 from Georg Koppen --- *** Bug 78565 has been marked as a duplicate of this bug. ***
[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78565 Georg Koppen changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Georg Koppen --- Yes, I just tested it, the fix for 79190 fixes this bug as well, thanks. *** This bug has been marked as a duplicate of bug 79190 ***
[Bug libstdc++/78565] New: undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78565 Bug ID: 78565 Summary: undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org Target Milestone: --- When testing r242055 to check whether it fixes bug 77459 (which it seems to do) I ran into another issue. This time I got: libtool: link: /home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc -B/home/ubuntu/build/gcc/./gcc -nostdinc++ -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/mingw/include -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/ -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include-shared -nostdlib /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/dllcrt2.o /home/ubuntu/build/gcc/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -L/home/ubuntu/build/gcc/./gcc -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 /home/ubuntu/build/gcc/./gcc/crtend.o -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -o .libs/libstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libstdc++.dll.a ../libsupc++/.libs/libsupc++convenience.a(new_opa.o): In function `ZnwjSt11align_val_t': /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/../../../gcc-test/libstdc++-v3/libsupc++/new_opa.cc:80: undefined reference to `aligned_alloc' collect2: error: ld returned 1 exit status make[5]: *** [libstdc++.la] Error 1 git blame gives me r240187 as the culprit.
[Bug libstdc++/77459] [6 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 --- Comment #11 from Georg Koppen --- (In reply to Jakub Jelinek from comment #10) > Assuming r242055 fixed it then. Yes, that issue is not showing up anymore when compiling with r242055.
[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 --- Comment #5 from Georg Koppen --- No, it is still broken after applying the patch to 6.2.0: ../src/c++11/.libs/libc++11convenience.a(debug.o): In function `format_word': /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:536: undefined reference to `snprintf' /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:536: undefined reference to `snprintf' /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:536: undefined reference to `snprintf' collect2: error: ld returned 1 exit status
[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 --- Comment #3 from Georg Koppen --- (In reply to Jonathan Wakely from comment #2) > It's 2016, how can snprintf not be supported still? I asked about that problem in #mingw-w64 a while ago and got the following answer: M$ does not provide `snprintf()` despite their non-standard extension `_snprintf()`. With mingw-w64, if the macro `__USE_MINGW_ANSI_STDIO` is defined to `1`, `snprintf` is a macro that redirects calls to `snprintf` to `__mingw_snprintf` instead. Not sure if that helps debugging/fixing.
[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 Georg Koppen changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from Georg Koppen --- FWIW: backing out r227885 (and r227888) "fixes" this problem for me.
[Bug libstdc++/77459] New: undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 Bug ID: 77459 Summary: undefined reference to `snprintf' when building mingw-w64 cross-compiler Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org Target Milestone: --- When switching GCC to 6.2.0 I get the following compiler error while trying to build the mingw-w64 cross-compiler: /bin/bash ../libtool --tag CXX --mode=link /home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc -B/home/ubuntu/build/gcc/./gcc -nostdinc++ -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/mingw/include -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/ -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include -Wl,-O1 -no-undefined -bindir "/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/../lib" -Wl,--gc-sections -std=gnu++98 -DDLL_EXPORT -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:22:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/../lib compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc -B/home/ubuntu/build/gcc/./gcc -nostdinc++ -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/mingw/include -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/ -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include-shared -nostdlib /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/dllcrt2.o /home/ubuntu/build/gcc/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -L/home/ubuntu/build/gcc/./gcc -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 /home/ubuntu/build/gcc/./gcc/crtend.o -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -o .libs/libstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libstdc++.dll.a ../src/c++11/.libs/libc++11convenience.a(debug.o): In function `format_word': /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535: undefined reference to `snprintf' /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535: undefined reference to `snprintf' /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535: undefined reference to `snprintf' collect2: error: ld returned 1 exit status Using GCC 5.1.0 works as expected.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #12 from Georg Koppen --- (In reply to Maxim Ostapenko from comment #10) > I've build Firefox locally with clang with optimizations disabled > (CFLAGS="-fsanitize=address -fsanitize-recover=address -O0") and got pretty > the same backtrace: What clang version/firefox version and build commands did you use for getting a clang build that crashes? Using the clang I have on my Debian machine + mozilla central does not seem to be enough.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 Georg Koppen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Georg Koppen --- Thanks a lot! I've informed the Mozilla people and updated their bug. Sorry for the noise.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #8 from Georg Koppen --- Looking at the stack trace again. It says "Memory access at offset 112 underflows this variable" yet ASan reports stack-buffer-overflow. I am confused. Shouldn't it report a stack-buffer-underflow then?
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #7 from Georg Koppen --- (In reply to Martin Liška from comment #6) > (In reply to Georg Koppen from comment #3) > > Created attachment 38573 [details] > > ASan stack trace > > > > This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is > > the ASan stack trace to begin with. > > Even thought I'm logged in, I'm not authorized to see the issue. > Can you please past the stack trace here? It's already attached to this bug: https://gcc.gnu.org/bugzilla/attachment.cgi?id=38573.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #5 from Georg Koppen --- And that's the g++ command line: /usr/bin/g++ -std=gnu++11 -o Unified_cpp_gfx_layers2.o -c -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/stl_wrappers -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /home/thomas/Arbeit/Tor/mozilla-central/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DGOOGLE_PROTOBUF_NO_RTTI -DOS_POSIX=1 -DOS_LINUX=1 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/layers -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/gfx/layers -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/ipc/ipdl/_ipdlheaders -I/home/thomas/Arbeit/Tor/mozilla-central/ipc/chromium/src -I/home/thomas/Arbeit/Tor/mozilla-central/ipc/glue -I/home/thomas/Arbeit/Tor/mozilla-central/docshell/base -I/home/thomas/Arbeit/Tor/mozilla-central/layout/base -I/home/thomas/Arbeit/Tor/mozilla-central/layout/generic -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/config -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/core -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/gpu -I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/utils -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nspr -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/mozilla-config.h -MD -MP -MF .deps/Unified_cpp_gfx_layers2.o.pp -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wc++14-compat -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fsanitize=address -Dxmalloc=myxmalloc -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -Os -fno-omit-frame-pointer -I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/cairo -I/home/thomas/Arbeit/Tor/mozilla-central/widget/gtk/compat-gtk3 -pthread -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wno-error=shadow /home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/gfx/layers/Unified_cpp_gfx_layers2.cpp Let me know if you need something more or I could do something to help tracking this down.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #4 from Georg Koppen --- Created attachment 38574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38574=edit .ii file Here comes the .ii file.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #3 from Georg Koppen --- Created attachment 38573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38573=edit ASan stack trace This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is the ASan stack trace to begin with.
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #1 from Georg Koppen --- I wonder if there are any good things I could do to debug this problem before looking at the stack trace itself. Any ideas?
[Bug sanitizer/71291] New: Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 Bug ID: 71291 Summary: Firefox with GCC reports stack-buffer-overflow but clang does not Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 38572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38572=edit Patch for building mozilla-central with GCC and ASan I recently reported a bug to the Mozilla team about a reproducible stack buffer overflow. To my surprise this ASan report only happens with GCC. Using different clang versions is working fine. The Mozilla folks concluded this is a GCC bug and closed the report as WORKSFORME. I've tested with GCC 5.2.0/5.3.1 and with the latest code on gcc-6-branch (which contains the latest ASan changes in GCC if I got that right) both Firefox 45 ESR and latest mozilla-central. The ASan crash is always reproducible for me. STR: 1) Build Firefox with a .mozconfig file like: . $topsrcdir/browser/config/mozconfig export CFLAGS="-fsanitize=address -Dxmalloc=myxmalloc" export CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc" # We need to add -ldl explicitely due to bug 1213698 export LDFLAGS="-fsanitize=address -ldl" ac_add_options --enable-address-sanitizer ac_add_options --disable-jemalloc ac_add_options --disable-elf-hack (if you build mozilla-central you need the attached asan.patch as well) 2) Go to http://lab.hakim.se/meny/ and move with the mouse to the left corner 3) The build crashes with a srack-buffer-overflow report.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 Georg Koppen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Georg Koppen --- We don't use any ESR24 anymore and no Lucid. Works for me.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 Georg Koppen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #14 from Georg Koppen --- Works for me given that probably no one is still using 10.04 and Firefox ESR24. Certainly we don't.
[Bug c++/71262] ICE when compiling mozilla-central (rev 298652)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71262 --- Comment #1 from Georg Koppen --- Created attachment 38556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38556=edit Compressed .ii file Attached is the compressed .ii file.
[Bug c++/71262] New: ICE when compiling mozilla-central (rev 298652)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71262 Bug ID: 71262 Summary: ICE when compiling mozilla-central (rev 298652) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org Target Milestone: --- Compiling mozilla-central (rev 298652) with the latest gcc (rev 236630) leads to a compiler error: 5:53.95 /home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/mozilla/ClearOnShutdown.h:98:1: interner Compiler-Fehler: Speicherzugriffsfehler 5:53.95 ClearOnShutdown(SmartPtr* aPtr, ShutdownPhase aPhase = ShutdownPhase::ShutdownFinal) 5:53.95 ^~~ 5:54.40 0xd4944f crash_signal 5:54.40../../gcc/toplev.c:333 5:54.43 0xa66c39 operand_equal_p(tree_node const*, tree_node const*, unsigned int) 5:54.44../../gcc/fold-const.c:2769 5:54.44 0xa66f17 operand_equal_p(tree_node const*, tree_node const*, unsigned int) 5:54.44../../gcc/fold-const.c:2751 5:54.48 0xfdcdc5 array_at_struct_end_p(tree_node*) 5:54.48../../gcc/tree.c:13100 5:54.51 0xfafdd7 check_array_ref 5:54.52../../gcc/tree-vrp.c:6427 5:54.52 0xfc5c15 check_array_ref 5:54.52../../gcc/tree-vrp.c:6413 5:54.52 0xfc5c15 check_array_bounds 5:54.52../../gcc/tree-vrp.c:6589 5:54.52 0xff0ae2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*)) 5:54.52../../gcc/tree.c:11650 5:54.52 0xff107e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*)) 5:54.52../../gcc/tree.c:11967 5:54.53 0xadced0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) 5:54.53../../gcc/gimple-walk.c:203 5:54.53 0xfbc350 check_all_array_refs 5:54.53../../gcc/tree-vrp.c:6636 5:54.53 0xfbc350 vrp_finalize 5:54.53../../gcc/tree-vrp.c:10202 5:54.53 0xfbc350 execute_vrp 5:54.53../../gcc/tree-vrp.c:10295 5:54.53 0xfbc350 execute 5:54.53../../gcc/tree-vrp.c:10380
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 --- Comment #4 from Georg Koppen --- It is using -lasan it seems: Executing: c++ -o firefox -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -v -fsanitize=address -Dxmalloc=myxmalloc -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fno-omit-frame-pointer /home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list -lpthread -fsanitize=address -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B ../../build/unix/gold -Wl,-Bsymbolic -rdynamic -Wl,-rpath-link,/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/dist/bin -Wl,-rpath-link,NONE/lib ../../xpcom/glue/standalone/libxpcomglue.a /home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list: INPUT("nsBrowserApp.o") INPUT("../../mozglue/build/AsanOptions.o") INPUT("../../mozglue/build/SSE.o") INPUT("../../mozglue/build/dummy.o") INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o") INPUT("../../mozglue/misc/StackWalk.o") INPUT("../../mozglue/misc/TimeStamp.o") INPUT("../../mozglue/misc/TimeStamp_posix.o") INPUT("../../mfbt/Compression.o") INPUT("../../mfbt/Decimal.o") INPUT("../../mfbt/Unified_cpp_mfbt0.o") INPUT("../../memory/fallible/fallible.o") Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-23' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151028 (Debian 5.2.1-23) COMPILER_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'firefox' '-Wall' '-Wempty-body' '-Woverloaded-virtual' '-Wsign-compare' '-Wwrite-strings' '-Wno-invalid-offsetof' '-Wcast-align' '-v' '-fsanitize=address' '-D' 'xmalloc=myxmalloc' '-fno-strict-aliasing' '-fno-rtti' '-fno-exceptions' '-fno-math-errno' '-std=gnu++11' '-pthread' '-pipe' '-D' 'NDEBUG' '-D' 'TRIMMED' '-g' '-freorder-blocks' '-Os' '-fno-omit-frame-pointer' '-fsanitize=address' '-B' '../../build/unix/gold' '-rdynamic' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccNcaQre.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o firefox /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L../../build/unix/gold -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. /usr/lib/gcc/x86_64-linux-gnu/5/libasan_preinit.o -lasan
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 Georg Koppen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Georg Koppen --- Resolving this as invalid then.
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 --- Comment #6 from Georg Koppen --- Alright, thanks. So, what happens with r215527 is that checking for dlopen() working properly in the configure script is not enough anymore to decide whether one needs -ldl needs to get added explicitly if address sanitizer is enabled. If it is not enabled the dlopen() check is still sufficient. If one uses dlsym() for instance instead the check for needing -ldl is working as before. I still don't understand exactly why this is needed but I guess this is a thing which needs to get fixed on the Mozilla side. Sorry for the noise.
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 --- Comment #1 from Georg Koppen --- To give a bit more context the flags used for compilation are: export CFLAGS="-fsanitize=address -Dxmalloc=myxmalloc" export CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc" export LDFLAGS="-fsanitize=address" (and there are some Firefox specific configure switches involved like ac_add_options --enable-address-sanitizer ac_add_options --disable-jemalloc ac_add_options --disable-elf-hack )
[Bug sanitizer/68650] New: Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 Bug ID: 68650 Summary: Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror') Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Beginning with r215527 building Firefox with Address Sanitizer enabled fails with errors like error: undefined reference to 'dlerror' error: undefined reference to 'dlsym' Testing with a clang (e.g. 3.6) including the upstream revision 218156 is working fine for me.
[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320 Georg Koppen changed: What|Removed |Added CC||gk at torproject dot org --- Comment #3 from Georg Koppen --- (In reply to Andreas Schwab from comment #2) > Please try this patch: This solves the issue for me.
[Bug c++/67876] ICE when compiling Firefox 38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67876 --- Comment #2 from Georg Koppen --- Created attachment 36464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36464=edit Preprocessed file for Unified_cpp_certverifier0.cpp Attached is the compressed preprocessed file. FWIW: GCC 5.2.0 is not affected either.
[Bug c++/67876] New: ICE when compiling Firefox 38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67876 Bug ID: 67876 Summary: ICE when compiling Firefox 38 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org Target Milestone: --- I get an internal compiler error when compiling Firefox 38 with GCC master. This is not happening with GCC 5.1.0: c++ -o Unified_cpp_certverifier0.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/ubuntu/build/tor-browser/config/gcc_hidden.h -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US -DNO_NSPR_10_SUPPORT -I/home/ubuntu/build/tor-browser/security/certverifier -I. -I/home/ubuntu/build/tor-browser/security/certverifier/../manager/boot/src -I/home/ubuntu/build/tor-browser/security/certverifier/../manager/ssl/src -I/home/ubuntu/build/tor-browser/security/certverifier/../pkix/include -I../../dist/include -I/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/include/nspr -I/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/include/nss -fPIC -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF .deps/Unified_cpp_certverifier0.o.pp -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -fsanitize=address -Dxmalloc=myxmalloc -fsanitize=undefined -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fno-omit-frame-pointer -Wall /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/security/certverifier/Unified_cpp_certverifier0.cpp In file included from /home/ubuntu/build/tor-browser/security/certverifier/NSSCertDBTrustDomain.cpp:21:0, from /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/security/certverifier/Unified_cpp_certverifier0.cpp:20: /home/ubuntu/build/tor-browser/security/certverifier/../pkix/include/pkix/ScopedPtr.h:78:46: internal compiler error: tree check: expected class 'expression', have 'exceptional' (template_parm_index) in tree_operand_check, at tree.h:3383 operator==(T* a, const ScopedPtr<T, Destroyer>& b) ^ 0xf00f37 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../.././gcc/tree.c:9573 0x65c1f0 expr_check(tree_node const*, char const*, int, char const*) ../.././gcc/tree.h:3287 0x65c1f0 tree_operand_check(tree_node const*, int, char const*, int, char const*) ../.././gcc/tree.h:3383 0x65c1f0 convert_template_argument ../.././gcc/cp/pt.c:7219 0x63161a coerce_template_parms ../.././gcc/cp/pt.c:7658 0x63358a lookup_template_class_1 ../.././gcc/cp/pt.c:8251 0x63358a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../.././gcc/cp/pt.c:8595 0x767b8d finish_template_type(tree_node*, tree_node*, int) ../.././gcc/cp/semantics.c:3051 0x6ee777 cp_parser_template_id ../.././gcc/cp/parser.c:14477 0x6eeac2 cp_parser_class_name ../.././gcc/cp/parser.c:20670 0x6ef336 cp_parser_qualifying_entity ../.././gcc/cp/parser.c:5984 0x6ef336 cp_parser_nested_name_specifier_opt ../.././gcc/cp/parser.c:5670 0x6e4210 cp_parser_simple_type_specifier ../.././gcc/cp/parser.c:15751 0x6e0525 cp_parser_type_specifier ../.././gcc/cp/parser.c:15448 0x6f14bb cp_parser_decl_specifier_seq ../.././gcc/cp/parser.c:12336 0x6f42f7 cp_parser_parameter_declaration ../.././gcc/cp/parser.c:19916 0x6f4c73 cp_parser_parameter_declaration_list ../.././gcc/cp/parser.c:19731 0x6f5279 cp_parser_parameter_declaration_clause ../.././gcc/cp/parser.c:19652 0x6ebd31 cp_parser_direct_declarator ../.././gcc/cp/parser.c:18438 0x6ebd31 cp_parser_declarator ../.././gcc/cp/parser.c:18316 GCC is configured just with ./configure --prefix=$INSTDIR/gcc --disable-multilib --enable-languages=c,c++ and Firefox is basically built with DEB_BUILD_HARDENING=1 and CFLAGS/CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fsanitize=undefined" + LDFLAGS="-fsanitize=address -fsanitize=undefined
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #8 from Georg Koppen gk at torproject dot org --- (In reply to Yury Gribov from comment #7) Have you tried patch proposed in bug 61422? No, as it is not applying cleanly anymore.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #11 from Georg Koppen gk at torproject dot org --- Working around was tricky, so I started bisecting LLVM/clang/compiler-rt. The first bad revision there is r193602. Might be worth filing an upstream bug (I don't have a Google account), I guess.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #13 from Georg Koppen gk at torproject dot org --- (In reply to Kostya Serebryany from comment #12) I am not sure what does your bisection of LLVM/clang/compiler-rt mean if you say that clang trunk works fine. There are two different issues here in this bug: one got moved to bug 61475 and *there* clang trunk is working fine. BUT for the original issue mentioned in this bug trunk is *not* working. See comment 8 above. I was referring to that comment when I talked about the bisection in my last comment. Anyway, I backed out the corresponding code parts in my GCC 4.9.0 and now everything is working when I am compiling with GCC 4.9.0 on Ubuntu Lucid.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #5 from Georg Koppen gk at torproject dot org --- (In reply to Georg Koppen from comment #3) (In reply to Kostya Serebryany from comment #1) Please 1. try building with -static-libasan I'll do that once I am done with investigating bug 61408. That didn't help either. I am getting the same crash.
[Bug c++/61482] New: ICE when compiling Firefox ESR 24 with r211488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61482 Bug ID: 61482 Summary: ICE when compiling Firefox ESR 24 with r211488 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org When compiling Firefox ESR 24 on an 64bit Ubuntu Precise machine with r211488 I get home/gk/asan/mozilla-esr24/layout/base/FrameLayerBuilder.cpp: In member function 'already_AddRefedmozilla::layers::ContainerLayer mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::FrameLayerBuilder::LayerManager*, nsIFrame*, nsDisplayItem*, const nsDisplayList, const mozilla::FrameLayerBuilder::ContainerParameters, const gfx3DMatrix*, uint32_t)': /home/gk/asan/mozilla-esr24/layout/base/FrameLayerBuilder.cpp:2804:1: internal compiler error: in set_value_range, at tree-vrp.c:453 FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder* aBuilder, ^ 0xd5acae set_value_range ../.././gcc/tree-vrp.c:452 0xd69f7d adjust_range_with_scev ../.././gcc/tree-vrp.c:3944 0xd69f7d vrp_visit_phi_node ../.././gcc/tree-vrp.c:8388 0xca4625 simulate_stmt ../.././gcc/tree-ssa-propagate.c:325 0xca47a7 process_ssa_edge_worklist ../.././gcc/tree-ssa-propagate.c:403 0xca5e35 ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**, tree_node**), ssa_prop_result (*)(gimple_statement_base*)) ../.././gcc/tree-ssa-propagate.c:877 0xd6f5a6 execute_vrp ../.././gcc/tree-vrp.c:9743 0xd6f5a6 execute ../.././gcc/tree-vrp.c:9824 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [FrameLayerBuilder.o] Error 1 make[6]: *** Waiting for unfinished jobs r211210 is still working. I compiled GCC with --prefix=/path/to/my/dir --disable-multilib --enable-languages=c,c++
[Bug sanitizer/61475] New: Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 Bug ID: 61475 Summary: Building Firefox with ASan is broken in the packaging step Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org As mentioned in bug 61408 building Firefox 24 (and probably later Firefox versions as well) with ASan is broken on GCC trunk. The build crashes in the packaging step as follows: Executing /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -a /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -f /home/gk/asan/mozilla-esr24/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache(resource://gre/); = ==22303==ERROR: AddressSanitizer: unknown-crash on address 0x2ad2d31bd3c0 at pc 0x2ad2d1803362 bp 0x7fff8f6149c0 sp 0x7fff8f6149b8 READ of size 16 at 0x2ad2d31bd3c0 thread T0 #0 0x2ad2d1803361 in nsIDHashKey ../../dist/include/nsHashKeys.h:375 #1 0x2ad2d1803361 in nsBaseHashtableET ../../dist/include/nsBaseHashtable.h:408 #2 0x2ad2d1803361 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::s_InitEntry(PLDHashTable*, PLDHashEntryHdr*, void const*) ../../dist/include/nsTHashtable.h:472 #3 0x2ad2d179ad39 in PL_DHashTableOperate /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/xpcom/build/pldhash.cpp:630 #4 0x2ad2d1805d75 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::PutEntry(nsID const, mozilla::fallible_t const) ../../dist/include/nsTHashtable.h:184 #5 0x2ad2d1805d75 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::PutEntry(nsID const) ../../dist/include/nsTHashtable.h:170 #6 0x2ad2d1805d75 in nsBaseHashtablensIDHashKey, nsFactoryEntry*, nsFactoryEntry*::Put(nsID const, nsFactoryEntry* const, mozilla::fallible_t const) ../../dist/include/nsBaseHashtable.h:147 #7 0x2ad2d1805d75 in nsBaseHashtablensIDHashKey, nsFactoryEntry*, nsFactoryEntry*::Put(nsID const, nsFactoryEntry* const) ../../dist/include/nsBaseHashtable.h:141 #8 0x2ad2d1806065 in nsComponentManagerImpl::RegisterCIDEntryLocked(mozilla::Module::CIDEntry const*, nsComponentManagerImpl::KnownModule*) /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:502 #9 0x2ad2d1809d35 in nsComponentManagerImpl::RegisterModule(mozilla::Module const*, mozilla::FileLocation*) /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:453 #10 0x2ad2d180aba2 in nsComponentManagerImpl::Init() /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:389 #11 0x2ad2d17a1fb0 in NS_InitXPCOM2 /home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp:467 #12 0x406d4b in main /home/gk/asan/mozilla-esr24/js/xpconnect/shell/xpcshell.cpp:1566 #13 0x2ad2d59b6c8c in __libc_start_main (/lib/libc.so.6+0x1ec8c) #14 0x407ea0 (/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell+0x407ea0) 0x2ad2d31bd3c0 is located 0 bytes inside of global variable 'kComponentManagerCID' from '/home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp' (0x2ad2d31bd3c0) of size 16 SUMMARY: AddressSanitizer: unknown-crash ../../dist/include/nsHashKeys.h:375 nsIDHashKey Shadow bytes around the buggy address: 0x055ada62fa20: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa30: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa40: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa50: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa60: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 =0x055ada62fa70: 00 00 f9 f9 f9 f9 f9 f9[00]00 f9 f9 f9 f9 f9 f9 0x055ada62fa80: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9 0x055ada62fa90: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 0x055ada62faa0: 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 0x055ada62fab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x055ada62fac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc ASan internal: fe ==22303==ABORTING
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #9 from Georg Koppen gk at torproject dot org --- (In reply to Georg Koppen from comment #8) Not sure about the problem in comment 3 yet which is probably better tracked in a different bug. I'll open one as soon as my build machine is not occupied anymore with bisecting the things related to the crash mentioned in the description. This is now bug 61475. Let's see what happens when I compile Firefox 24 on Lucid with LLVM/Clang trunk...
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #3 from Georg Koppen gk at torproject dot org --- (In reply to Kostya Serebryany from comment #1) Please 1. try building with -static-libasan I'll do that once I am done with investigating bug 61408. 2. provide full reproduction steps 1) Take an Ubuntu Precise. 2) Compile GCC (I used the trunk from June 4 as the current has an ICE when compiling Firefox which I need to report as well). I compiled it with --prefix=/path/to/my/dir --disable-multilib --enable-languages=c,c++. 3) Grab the latest Firefox ESR 24 source code (https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-esr/source/firefox-24.6.0esr.source.tar.bz2). 4) Extract it and change into mozilla-esr24. 5) Save the attached mozconfig as .mozconfig in mozille-esr24. 6) Adjust your path to point to your freshly compiled GCC and point LD_LIBRARY_PATH to your GCC-dir/lib64 (assuming you are compiling on a 64bit system). 7) Run |make -j4 -f client.mk build|. 8) After successful compilation package Firefox with |make -C obj* package INNER_MAKE_PACKAGE=true|. 9) It crashes as mentioned in the description.
[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475 --- Comment #4 from Georg Koppen gk at torproject dot org --- Created attachment 32924 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32924action=edit .mozconfig for building Firefox ESR 24 with ASan
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #10 from Georg Koppen gk at torproject dot org --- Okay. LLVM/Clang trunk does not cope with the packaging step either. Sending the crash through asan_symbolize.py gives: Executing /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -a /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -f /home/gk/asan/mozilla-esr24/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache(resource://gre/); ASAN:SIGSEGV = ==4017==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x sp 0x2b9955a94738 bp 0x2b9955a947f0 T2) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ??:0 ?? Thread T2 created by T0 here: BFD: Dwarf Error: found dwarf version '4', this reader only handles version 2 and 3 information. #0 0x48aa4f in pthread_create ??:0 BFD: Dwarf Error: found dwarf version '4', this reader only handles version 2 and 3 information. #1 0x2b994b0d4d4e in _PR_CreateThread /home/gk/asan/mozilla-esr24/nsprpub/pr/src/pthreads/ptthread.c:0 BFD: Dwarf Error: found dwarf version '0', this reader only handles version 2 and 3 information. #2 0x2b994b0d48b7 in PR_CreateThread ??:0 ==4017==ABORTING I am trying to work around that problem until somebody has a good idea on what is going on/how to debug that further.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #8 from Georg Koppen gk at torproject dot org --- While I am still unable to compile/test Firefox 24 with clang trunk I managed to compile it with clang's r196090 which is the one r205695 merged. And there the problem occurs as well. Thus, we know at least that it is not a GCC specific issue. Not sure about the problem in comment 3 yet which is probably better tracked in a different bug. I'll open one as soon as my build machine is not occupied anymore with bisecting the things related to the crash mentioned in the description.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #7 from Georg Koppen gk at torproject dot org --- (In reply to Jakub Jelinek from comment #6) I'd say there is no point in doing that. Just build the compiler-rt library and link it in statically (-static-libasan) with gcc instead of the gcc one. Hmm... how do I do that exactly? I have some libclang_rt.* in Release+Asserts/lib/clang/3.5.0/lib/linux but seem not to be able to get that going... And I don't get any Firefox version between 24 and trunk compiled with 3.5.0 (for different reasons), thus that way is blocked as well atm.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #3 from Georg Koppen gk at torproject dot org --- (In reply to Kostya Serebryany from comment #2) Does this happen with GCC trunk? Hard to say as it crashes differently: Executing /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -a /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/ -f /home/gk/asan/mozilla-esr24/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache(resource://gre/); = ==22303==ERROR: AddressSanitizer: unknown-crash on address 0x2ad2d31bd3c0 at pc 0x2ad2d1803362 bp 0x7fff8f6149c0 sp 0x7fff8f6149b8 READ of size 16 at 0x2ad2d31bd3c0 thread T0 #0 0x2ad2d1803361 in nsIDHashKey ../../dist/include/nsHashKeys.h:375 #1 0x2ad2d1803361 in nsBaseHashtableET ../../dist/include/nsBaseHashtable.h:408 #2 0x2ad2d1803361 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::s_InitEntry(PLDHashTable*, PLDHashEntryHdr*, void const*) ../../dist/include/nsTHashtable.h:472 #3 0x2ad2d179ad39 in PL_DHashTableOperate /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/xpcom/build/pldhash.cpp:630 #4 0x2ad2d1805d75 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::PutEntry(nsID const, mozilla::fallible_t const) ../../dist/include/nsTHashtable.h:184 #5 0x2ad2d1805d75 in nsTHashtablensBaseHashtableETnsIDHashKey, nsFactoryEntry* ::PutEntry(nsID const) ../../dist/include/nsTHashtable.h:170 #6 0x2ad2d1805d75 in nsBaseHashtablensIDHashKey, nsFactoryEntry*, nsFactoryEntry*::Put(nsID const, nsFactoryEntry* const, mozilla::fallible_t const) ../../dist/include/nsBaseHashtable.h:147 #7 0x2ad2d1805d75 in nsBaseHashtablensIDHashKey, nsFactoryEntry*, nsFactoryEntry*::Put(nsID const, nsFactoryEntry* const) ../../dist/include/nsBaseHashtable.h:141 #8 0x2ad2d1806065 in nsComponentManagerImpl::RegisterCIDEntryLocked(mozilla::Module::CIDEntry const*, nsComponentManagerImpl::KnownModule*) /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:502 #9 0x2ad2d1809d35 in nsComponentManagerImpl::RegisterModule(mozilla::Module const*, mozilla::FileLocation*) /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:453 #10 0x2ad2d180aba2 in nsComponentManagerImpl::Init() /home/gk/asan/mozilla-esr24/xpcom/components/nsComponentManager.cpp:389 #11 0x2ad2d17a1fb0 in NS_InitXPCOM2 /home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp:467 #12 0x406d4b in main /home/gk/asan/mozilla-esr24/js/xpconnect/shell/xpcshell.cpp:1566 #13 0x2ad2d59b6c8c in __libc_start_main (/lib/libc.so.6+0x1ec8c) #14 0x407ea0 (/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell+0x407ea0) 0x2ad2d31bd3c0 is located 0 bytes inside of global variable 'kComponentManagerCID' from '/home/gk/asan/mozilla-esr24/xpcom/build/nsXPComInit.cpp' (0x2ad2d31bd3c0) of size 16 SUMMARY: AddressSanitizer: unknown-crash ../../dist/include/nsHashKeys.h:375 nsIDHashKey Shadow bytes around the buggy address: 0x055ada62fa20: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa30: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa40: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa50: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 0x055ada62fa60: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 =0x055ada62fa70: 00 00 f9 f9 f9 f9 f9 f9[00]00 f9 f9 f9 f9 f9 f9 0x055ada62fa80: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9 0x055ada62fa90: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 0x055ada62faa0: 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 0x055ada62fab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x055ada62fac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc ASan internal: fe ==22303==ABORTING LLVM trunk? Have not tried yet. Shall I?
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #5 from Georg Koppen gk at torproject dot org --- (In reply to Kostya Serebryany from comment #4) LLVM trunk? Have not tried yet. Shall I? asan is being developed in LLVM trunk. So if there is a bug in run-time it's better to investigate the freshest variant in LLVM trunk The fix will have to go there first anyway. Okay. Then I'll do that. Note that the last crash is happening on my Precise system as well now. Thus, I guess this is a different issue worth another bug. Anyway, I'll post back when I have convinced LLVM/Clang to compile Firefox.
[Bug sanitizer/61408] New: r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 Bug ID: 61408 Summary: r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Trying to build Firefox 24 ESR on Lucid with ASan and 4.9.0 leads to a crash during the packaging of the build: Executing /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell -g /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/bin/ -a /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/bin/ -f /home/ubuntu/build/tor-browser/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache(resource://gre/); ASAN:SIGSEGV = ==22869==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x sp 0x2b0f084bf678 bp 0x2b0f084bf780 T2) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ??:0 ?? Thread T2 created by T0 here: #0 0x2b0ec8ea572a in __interceptor_pthread_create ../../.././libsanitizer/asan/asan_interceptors.cc:183 #1 0x2b0ef7b75269 in _PR_CreateThread /home/ubuntu/build/tor-browser/nsprpub/pr/src/pthreads/ptthread.c:444 #2 0x2b0ef7b778ae in PR_CreateThread /home/ubuntu/build/tor-browser/nsprpub/pr/src/pthreads/ptthread.c:527 #3 0x2b0ede4a9286 in nsThread::Init() /home/ubuntu/build/tor-browser/xpcom/threads/nsThread.cpp:332 #4 0x2b0ee5d7d57c (/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so+0x1bdfe57c) ==22869==ABORTING After a lot of bisecting it turns out that r205695 is the first revision that breaks. Oddly, this is not a problem if building and using 4.9.0 on Ubuntu Precise. There building and packaging Firefox 24 ESR is working fine.
[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408 --- Comment #1 from Georg Koppen gk at torproject dot org --- I am happy to debug this further (and am, of course, interested in a fix/workaround). Let me know what you need.
[Bug sanitizer/61314] Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid and Precise using libfaketime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 Georg Koppen gk at torproject dot org changed: What|Removed |Added Summary|Building GCC 4.9.0 breaks |Building GCC 4.9.0 breaks |in libbacktrace on Ubuntu |in libbacktrace on Ubuntu |Lucid Lynx |Lucid and Precise using ||libfaketime --- Comment #3 from Georg Koppen gk at torproject dot org --- I made some more tests. Building on UbuntuPrecise is breaking as well with a similar error while compiling 4.9.0 and not faking timestamps with libfaketime works both on Lucid and Precise. This seems to support my analysis in comment 2.
[Bug sanitizer/61314] New: Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid Lynx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 Bug ID: 61314 Summary: Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid Lynx Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org When building gcc 4.9.0 on Ubuntu Lucid the build breaks with the following error: /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../gcc-4.9.0/libbacktrace -I ../gcc-4.9.0/libbacktrace/../include -I ../gcc-4.9.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=dwarf.lo -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -c -o dwarf.lo ../gcc-4.9.0/libbacktrace/dwarf.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../gcc-4.9.0/libbacktrace -I ../gcc-4.9.0/libbacktrace/../include -I ../gcc-4.9.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=dwarf.lo -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -c ../gcc-4.9.0/libbacktrace/dwarf.c -o dwarf.o ../gcc-4.9.0/libbacktrace/dwarf.c: In function 'dwarf_lookup_pc': ../gcc-4.9.0/libbacktrace/dwarf.c:2678: warning: implicit declaration of function '__atomic_load_n' ../gcc-4.9.0/libbacktrace/dwarf.c:2678: error: '__ATOMIC_ACQUIRE' undeclared (first use in this function) ../gcc-4.9.0/libbacktrace/dwarf.c:2678: error: (Each undeclared identifier is reported only once ../gcc-4.9.0/libbacktrace/dwarf.c:2678: error: for each function it appears in.) ../gcc-4.9.0/libbacktrace/dwarf.c:2738: warning: implicit declaration of function '__atomic_store_n' ../gcc-4.9.0/libbacktrace/dwarf.c:2738: error: '__ATOMIC_RELEASE' undeclared (first use in this function) ../gcc-4.9.0/libbacktrace/dwarf.c: In function 'dwarf_fileline': ../gcc-4.9.0/libbacktrace/dwarf.c:2873: error: '__ATOMIC_ACQUIRE' undeclared (first use in this function) ../gcc-4.9.0/libbacktrace/dwarf.c: In function 'backtrace_dwarf_add': ../gcc-4.9.0/libbacktrace/dwarf.c:3006: error: '__ATOMIC_ACQUIRE' undeclared (first use in this function) make[2]: Leaving directory `/home/ubuntu/build/gcc/libbacktrace' make[2]: *** [dwarf.lo] Error 1 It works fine on Ubuntu Precise. The gcc version on Lucid is 4.4.3 and on Precise 4.6.3. I configured the 4.9.0 build with --prefix=path/to/my/dir --disable-multilib --enable-languages=c,c++
[Bug sanitizer/61314] Building GCC 4.9.0 breaks in libbacktrace on Ubuntu Lucid Lynx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 --- Comment #2 from Georg Koppen gk at torproject dot org --- Created attachment 32856 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32856action=edit config.log Attached is the config.log. Here comes some additional information that might help to understand this bug. The build failure does not happen when running |make| but |make install| which is surprising. It might be due to our deterministic build setup which uses Gitian and libfaketime. We had and still have a lot of trouble compiling GCC when using libfaketime and what we are currently doing is compiling GCC with -j1 we seems to avoid the problems involved in faking the timestamps. Until now. The lines immediately before the pieces I posted above are: make[2]: Leaving directory `/home/ubuntu/build/gcc/gcc' make[2]: warning: Clock skew detected. Your build may be incomplete. make[2]: Entering directory `/home/ubuntu/build/gcc/intl' make[2]: Warning: File `Makefile' has modification time 0.23 s in the future make[2]: Nothing to be done for `install'. make[2]: warning: Clock skew detected. Your build may be incomplete. make[2]: Leaving directory `/home/ubuntu/build/gcc/intl' make[2]: Entering directory `/home/ubuntu/build/gcc/libbacktrace' make[2]: Warning: File `dwarf.lo' has modification time 0.035 s in the future Here is what seems to happen: the build system seems to realize that there might have been issues in the build and is recompiling dwarf.c during the make-install-step but not using the compiler the configure was for but the one Lucid ships. That this is a non-issue for compiling on Precise might be due to me not compiling 4.9.0 in the Gitian/libfaketime environment. Does this make some sense? If so, do you see a workaround for us here? Pointing to the compiler the configure setup was for after |make| ran? Or...?