[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 Oleg Smolsky changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #14 from Oleg Smolsky --- The ASan issue was due to the memory limit applied via setrlimit(). The virtual size (in this -fPIC -pie build) is really huge and so memory allocations were failing. I'll confirm the TSan case in a bit. Than

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #13 from Oleg Smolsky --- Created attachment 30875 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30875&action=edit another stack ASAN_OPTIONS=malloc_context_size=1 gets me passed the initial issue, but the code gets stuck here:

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #8 from Kostya Serebryany --- ouch! free calling malloc. this is not going to work :) This code has changed since our last merge to gcc -- the trunk version does not have strerror call any more. I really hope to make another merge

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #7 from Oleg Smolsky --- Created attachment 30874 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30874&action=edit full stack Here is the full stack. It comes from the very same spot in my app. As for the minimal repro - that's

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #12 from Kostya Serebryany --- You can also try ASAN_OPTIONS=malloc_context_size=1 (or 0) this will eliminate this particular call to mmap (but will reduce the usefulness of asan report)

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #11 from Oleg Smolsky --- Sure. The verbose thing does not yield much: ==1236== Parsed ASAN_OPTIONS: verbosity=1 ==1236== AddressSanitizer: libc interceptors initialized || `[0x10007fff8000, 0x7fff]` || HighMem|| || `[0x02

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #10 from Kostya Serebryany --- Your stack traces tells me this: __sanitizer::MmapOrDie calls strerror, which means that mmap call failed. This may happen if the process OOM-ed (unlikely in your case), or may have some kind of limit (

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread oleg at smolsky dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #9 from Oleg Smolsky --- Hold on, I don't get the "more memory" bit. This happens very early, before anything else of merit. Also, it turns out that this isn't a deadlock, the main thread is spinning inside asan code. USER PID %

[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program

2013-09-20 Thread kcc at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #6 from Kostya Serebryany --- Is that the full stack trace? (As usual, a reproducer will help us much)