http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #26 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #25)
> Even with this workaround asan is almost unusable with the buggy kernel.
> I suspect that when a process has too many mappings it gets too slow.
> The machin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #23 from Kostya Serebryany ---
Relevant Kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=67651
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #22 from Kostya Serebryany ---
A quick workaround would be to change
static const uptr kUserMapSize = 1 << 16;
in sanitizer_common/sanitizer_allocator.h
to something like 17 or 18.
We can also try using mremap.
However I'd like to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #21 from Evgeniy Stepanov ---
A reproducer without ASan:
#include
#include
#include
#include
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i < 100; ++i)
mmap(p + i * 4096, 4096, PROT_WRITE | PROT_READ, MAP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #20 from Evgeniy Stepanov ---
I can confirm that the issue can be reproduced on 3.13.0-5-generic (ubuntu
14.04 candidate), and can not be reproduced on 3.11.0-15-generic (ubuntu
13.10).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #19 from Kostya Serebryany ---
(In reply to Kostya Serebryany from comment #18)
> eugenis@ says he sees something similar on Ubuntu 13.10.
Actually, only on Ubuntu 14.04 candidate.
Looks like a fresh regression in Kernel.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #17 from Kostya Serebryany ---
When I look at my /proc/PID/maps of cc1plus, I see this:
...
6100-6103 rw-p 00:00 0
6103-6110 ---p 00:00 0
6110-61100098 rw-p 00:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #16 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #15)
> This looks very weird:
> 60200120-60200121 rw-p 00:00 0
> 60200121-60200122 rw-p 00:00 0
>
> We have two adjacent mappings wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #15 from Kostya Serebryany ---
This looks very weird:
60200120-60200121 rw-p 00:00 0
60200121-60200122 rw-p 00:00 0
We have two adjacent mappings with the same perms
which are not merged by the ke
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #14 from H.J. Lu ---
Created attachment 31946
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31946&action=edit
/proc/cc1plus/{maps,smaps,status}
This is the output of "cat /proc/cc1plus/{maps,smaps,status}".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #13 from Kostya Serebryany ---
> If you run cc1plus under GDB, you will get
>
> Breakpoint 6, __sanitizer::Report (
> format=format@entry=0x284f6f0 "ERROR: %s failed to allocate 0x%zx (%zd)
> bytes of %s: %d\n")
This happens due
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #12 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #10)
> H.J., can you send the contents of /proc/PID/{maps,smaps,status}
> of the failing process before it dies?
> (you can use ASAN_OPTIONS=sleep_before_dying=1000)
If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #11 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #9)
> > It still fails for me. It has nothing to do with "make -jN". When I
>
> I tried running this on the fresh gcc trunk.
>
> During the 3-rd stage I get this:
> ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #10 from Kostya Serebryany ---
H.J., can you send the contents of /proc/PID/{maps,smaps,status}
of the failing process before it dies?
(you can use ASAN_OPTIONS=sleep_before_dying=1000)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #9 from Kostya Serebryany ---
> It still fails for me. It has nothing to do with "make -jN". When I
I tried running this on the fresh gcc trunk.
During the 3-rd stage I get this:
checking how to run the C preprocessor... ../libibert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> Can't reproduce this, at least not if I use sufficiently lower make -jN
> factor (used -j2). With that
> ../configure --enable-languages=c,c++,fortran,java,lto,objc,obj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #7 from Jakub Jelinek ---
Can't reproduce this, at least not if I use sufficiently lower make -jN factor
(used -j2). With that
../configure --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go
--with-build-config=bootstrap-asan -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #6 from H.J. Lu ---
Created attachment 31788
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31788&action=edit
strace -o log -e mmap,munmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> BTW, are you sure you don't have some ulimit imposed limits (say on virtual
> address space)?
[hjl@gnu-mic-2 gcc]$ ulimit -a
core file size (blocks, -c) 0
data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #4 from Jakub Jelinek ---
BTW, are you sure you don't have some ulimit imposed limits (say on virtual
address space)?
Can you strace it (perhaps just strace -o log -e mmap,munmap )?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #3 from H.J. Lu ---
Breakpoint 6, __sanitizer::Report (
format=format@entry=0x2821768 "ERROR: %s failed to allocate 0x%zx (%zd)
bytes of %s: %d\n")
---Type to continue, or q to quit---
at
/export/gnu/import/git/gcc/libsanitiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #2 from Jakub Jelinek ---
It doesn't matter which change triggered it, this looks like libsanitizer
internal error, it assumes no internal allocations will need to be large, but
apparently some are. So, the question is what is the bac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
27 matches
Mail list logo
