heap-checker_unittest.sh hangs on Ubuntu-12.04 x86_64

[GoogleCodeExporter]

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

Original issue reported on code.google.com by cjae...@gmail.com on 3 May 2012 at 5:18

• Merged into: #479

[GoogleCodeExporter]

This sounds very much like 
http://code.google.com/p/gperftools/issues/detail?id=423. Can you confirm which 
glibc version that you are using.

Original comment by chapp...@gmail.com on 4 May 2012 at 4:01

[GoogleCodeExporter]

Looks like 2.15 from libc6-2.15-0ubuntu10

Original comment by cjae...@gmail.com on 4 May 2012 at 4:14

[GoogleCodeExporter]

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.

Original comment by chapp...@gmail.com on 4 May 2012 at 5:45

[GoogleCodeExporter]

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.

Original comment by chapp...@gmail.com on 15 May 2012 at 5:26

• Changed state: Accepted

[GoogleCodeExporter]

I thought I'd already confirmed that I was using 2.15...?

Original comment by cjae...@gmail.com on 15 May 2012 at 5:29

[GoogleCodeExporter]

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.

Original comment by chapp...@gmail.com on 15 May 2012 at 7:41

[GoogleCodeExporter]

A patch has been submitted to fix this in issue-479.

Original comment by chapp...@gmail.com on 3 Nov 2012 at 3:04

• Changed state: Duplicate