Closed GoogleCodeExporter closed 9 years ago
I will need backtraces of all threads.
Also, please note that, RHEL6 issue was discovered in 2.1 and is fixed already
on master.
Original comment by alkondratenko
on 1 Oct 2013 at 5:25
Here's the full backtrace for all threads. Let me know if you need anything
else. Thanks, --DD
Original comment by ddevie...@gmail.com
on 2 Oct 2013 at 1:03
Attachments:
I need to think about your case a bit more (and can't do in now in normal work
time). But there's great chance that treatment proposed in
https://groups.google.com/forum/#!msg/google-perftools/PQR4zQ6CQYs/53RAJe-leW8J
will help you.
Original comment by alkondratenko
on 2 Oct 2013 at 8:18
Indeed.
Thread 1 took memory region map (as part of initialization of heap checker) and
then while holding this lock it did allocation via low level alloc that called
mmap, that our mmap recorder intercepted and called libunwind to capture
backtrace. Libunwind tries to grab it's internal mutex.
Meanwhile thread 10 was recording allocation and invoked libunwind to capture
backtrace. That took libunwind lock. But libunwind internally did mmap which we
tried to record and as part of that take memory region map.
One of my commits above fixes exactly that lack of ordering between memory
region map lock and libunwind lock.
I think I'll merge it today.
Thanks for raising it and being quick with providing all necessary evidence.
Original comment by alkondratenko
on 12 Oct 2013 at 10:20
Merged
https://code.google.com/p/gperftools/source/detail?r=db0d5730ee059d72b895fbead52
37f9cb5bbf98a
Thanks
Original comment by alkondratenko
on 12 Oct 2013 at 11:20
Original issue reported on code.google.com by
ddevie...@gmail.com
on 1 Oct 2013 at 11:15