My favorites | Sign in
Project Home Downloads Wiki Issues Source Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 428: heap-checker_unittest.sh hangs on Ubuntu-12.04 x86_64
3 people starred this issue and may be notified of changes. Back to list
Status:  Duplicate
Merged:  issue 479
Owner:  chapp...@gmail.com
Closed:  Nov 2012


Sign in to add a comment
 
Reported by cjae...@gmail.com, May 3, 2012
What steps will reproduce the problem?
1. configure
2. make
3. run heap-checker_unittest.sh

What is the expected output? What do you see instead?
The HEAPCHECK=local stage should pass. Instead, it hangs.

What version of the product are you using? On what operating system?
Latest version from head. Ubuntu 12.04 x86_64

Please provide any additional information below.

The hang appears to be due to a recursive lock on heap_checker_lock. The sscanf call when reading /proc/<pid>/maps in src/base/sysinfo.cc appears to be causing a memory allocation, where it presumably didn't before. 

Stacktrace:

#0  0x00007fd111ae2510 in __nanosleep_nocancel () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007fd111d27cb9 in base::internal::SpinLockDelay (w=0x7fd111f3f2b0, value=2, loop=6177) at ./src/base/spinlock_linux-inl.h:89
#2  0x00007fd111d26eb7 in SpinLock::SlowLock (this=0x7fd111f3f2b0) at src/base/spinlock.cc:138
#3  0x00007fd111d0c88c in Lock (this=0x7fd111f3f2b0) at src/base/spinlock.h:92
#4  SpinLockHolder (l=0x7fd111f3f2b0, this=0x7fffc8087130) at src/base/spinlock.h:162
#5  NewHook (ptr=0x83c000, size=256) at src/heap-checker.cc:581
#6  0x00007fd111d1cd4a in MallocHook::InvokeNewHookSlow (p=0x83c000, s=256) at src/malloc_hook.cc:525
#7  0x00007fd111d2b143 in InvokeNewHook (s=256, p=0x83c000) at src/malloc_hook-inl.h:161
#8  do_realloc_with_callback (invalid_get_size_fn=<optimized out>, invalid_free_fn=<optimized out>, new_size=<optimized out>, old_ptr=<optimized out>)
    at src/tcmalloc.cc:1242
#9  do_realloc (new_size=<optimized out>, old_ptr=<optimized out>) at src/tcmalloc.cc:1249
#10 tc_realloc (old_ptr=<optimized out>, new_size=256) at src/tcmalloc.cc:1549
#11 0x00007fd11125866f in _IO_vfscanf () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00007fd111271360 in vsscanf () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x00007fd11125c317 in sscanf () from /lib/x86_64-linux-gnu/libc.so.6
#14 0x00007fd111d2669b in ProcMapsIterator::NextExt (this=0x7fffc8088dd0, start=0x7fffc8087998, end=0x7fffc80879a0, flags=0x7fffc80879b8, offset=0x7fffc80879a8, 
    inode=0x7fffc80879b0, filename=0x7fffc80879c0, file_mapping=0x0, file_pages=0x0, anon_mapping=0x0, anon_pages=0x0, dev=0x0) at src/base/sysinfo.cc:721
#15 0x00007fd111d269af in ProcMapsIterator::Next (this=<optimized out>, start=<optimized out>, end=<optimized out>, flags=<optimized out>, offset=<optimized out>, 
    inode=<optimized out>, filename=0x7fffc80879c0) at src/base/sysinfo.cc:661
#16 0x00007fd111d0f819 in HeapLeakChecker::UseProcMapsLocked (proc_maps_task=HeapLeakChecker::DISABLE_LIBRARY_ALLOCS) at src/heap-checker.cc:913
#17 0x00007fd111d100b2 in HeapLeakChecker_InternalInitStart () at src/heap-checker.cc:2036
#18 0x00007fd111d064f8 in google_init_module_init_start () at src/heap-checker.cc:2126
#19 GoogleInitializer (dtor=0, ctor=<optimized out>, name=0x7fd111d30195 "init_start", this=0x7fd111f3f2f0) at src/base/googleinit.h:45
#20 __static_initialization_and_destruction_0 (__initialize_p=<optimized out>, __priority=<optimized out>) at src/heap-checker.cc:2126
#21 _GLOBAL__sub_I_heap_checker.cc(void) () at src/heap-checker.cc:2377

May 4, 2012
Project Member #1 chapp...@gmail.com
This sounds very much like https://code.google.com/p/gperftools/issues/detail?id=423. Can you confirm which glibc version that you are using.

May 4, 2012
#2 cjae...@gmail.com
Looks like 2.15 from libc6-2.15-0ubuntu10
May 4, 2012
Project Member #3 chapp...@gmail.com
Ok so very likely related to  issue 423  then. Looks like we need to find a creative way to circumvent this allocation that glibc has introduced in sscanf.
May 15, 2012
Project Member #4 chapp...@gmail.com
Can you please check which version of gnu libc you are using? In speaking with the gnu libc guys, version 2.15 introduced a bug in _IO_vfscanf_internal where alloca is avoided altogether and realloc is called instead. The intent was for realloc to only be  called for large buffers. In 2.16 this is fixed such that alloca is still used for small buffers.
Status: Accepted
Owner: chapp...@gmail.com
May 15, 2012
#5 cjae...@gmail.com
I thought I'd already confirmed that I was using 2.15...?
May 15, 2012
Project Member #6 chapp...@gmail.com
Sorry, the comment history was collapsed and I missed that :). Going to 2.14 or 2.16 should fix the issue in the interim. I'll have to look at a longer term fix in the meantime.
Nov 3, 2012
Project Member #7 chapp...@gmail.com
A patch has been submitted to fix this in issue-479.
Status: Duplicate
Mergedinto: 479
Sign in to add a comment

Powered by Google Project Hosting