[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

2018-03-10 Thread gk at torproject dot org
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

2018-03-10 Thread gk at torproject dot org
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

2016-11-28 Thread gk at torproject dot org
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

2016-11-28 Thread gk at torproject dot org
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

2016-09-29 Thread gk at torproject dot org
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

2016-09-27 Thread gk at torproject dot org
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

2016-09-27 Thread gk at torproject dot org
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

2016-09-02 Thread gk at torproject dot org
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

2016-06-01 Thread gk at torproject dot org
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

2016-05-31 Thread gk at torproject dot org
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

2016-05-29 Thread gk at torproject dot org
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

2016-05-27 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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

2016-05-26 Thread gk at torproject dot org
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)

2016-05-24 Thread gk at torproject dot org
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)

2016-05-24 Thread gk at torproject dot org
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')

2015-12-03 Thread gk at torproject dot org
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')

2015-12-03 Thread gk at torproject dot org
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')

2015-12-03 Thread gk at torproject dot org
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')

2015-12-01 Thread gk at torproject dot org
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')

2015-12-01 Thread gk at torproject dot org
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

2015-11-27 Thread gk at torproject dot org
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

2015-10-08 Thread gk at torproject dot org
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

2015-10-06 Thread gk at torproject dot org
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

2014-06-24 Thread gk at torproject dot org
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

2014-06-16 Thread gk at torproject dot org
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

2014-06-16 Thread gk at torproject dot org
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

2014-06-12 Thread gk at torproject dot org
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

2014-06-12 Thread gk at torproject dot org
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

2014-06-11 Thread gk at torproject dot org
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

2014-06-11 Thread gk at torproject dot org
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

2014-06-11 Thread gk at torproject dot org
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

2014-06-11 Thread gk at torproject dot org
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

2014-06-11 Thread gk at torproject dot org
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

2014-06-09 Thread gk at torproject dot org
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

2014-06-05 Thread gk at torproject dot org
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

2014-06-04 Thread gk at torproject dot org
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

2014-06-04 Thread gk at torproject dot org
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

2014-06-03 Thread gk at torproject dot org
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

2014-06-03 Thread gk at torproject dot org
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

2014-05-28 Thread gk at torproject dot org
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

2014-05-26 Thread gk at torproject dot org
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

2014-05-26 Thread gk at torproject dot org
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...?