https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78565
Georg Koppen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190
Georg Koppen changed:
What|Removed |Added
CC||gk at torproject dot org
--- Comment #13
++
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
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&action=edit
Compressed .ii file
Attached is the compressed .ii file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
Georg Koppen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
Georg Koppen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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?
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&action=edit
ASan stack trace
This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is
the ASan stack tra
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&action=edit
.ii file
Here comes the .ii file.
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
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
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291
Georg Koppen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 back
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.
erity: 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
erity: 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:
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
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 `snp
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/../../../
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314
--- Comment #2 from Georg Koppen ---
Created attachment 32856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32856&action=edit
config.log
Attached is the config.log. Here comes some additional information that might
help to understand this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314
Georg Koppen changed:
What|Removed |Added
Summary|Building GCC 4.9.0 breaks |Building GCC 4.9.0 breaks
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #1 from Georg Koppen ---
I am happy to debug this further (and am, of course, interested in a
fix/workaround). Let me know what you need.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #3 from Georg Koppen ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #5 from Georg Koppen ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #7 from Georg Koppen ---
(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...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #8 from Georg Koppen ---
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 th
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #9 from Georg Koppen ---
(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 anymo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
--- Comment #3 from Georg Koppen ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
--- Comment #4 from Georg Koppen ---
Created attachment 32924
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32924&action=edit
.mozconfig for building Firefox ESR 24 with ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #10 from Georg Koppen ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
--- Comment #5 from Georg Koppen ---
(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.
: 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_AddRefed
mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #11 from Georg Koppen ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408
--- Comment #13 from Georg Koppen ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61475
--- Comment #8 from Georg Koppen ---
(In reply to Yury Gribov from comment #7)
> Have you tried patch proposed in bug 61422?
No, as it is not applying cleanly anymore.
++
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
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&action=edit
Preprocessed file for Unified_cpp_certverifier0.cpp
Attached is the compressed preprocessed file. FWIW: GCC 5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
Georg Koppen changed:
What|Removed |Added
CC||gk at torproject dot org
--- Comment #3
NCONFIRMED
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
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=addres
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-
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 add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650
Georg Koppen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
48 matches
Mail list logo
