Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

heap-checker_unittest.sh hangs on Ubuntu-12.04 x86_64 #431

Closed
alk opened this issue Aug 23, 2015 · 7 comments
Closed

heap-checker_unittest.sh hangs on Ubuntu-12.04 x86_64 #431

alk opened this issue Aug 23, 2015 · 7 comments
Assignees
@alk
Labels
Priority-Medium Status-Duplicate Type-Defect

Comments

@alk
Copy link
Contributor

alk commented Aug 23, 2015

Originally reported on Google Code with ID 428

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

Reported by cjaeger on 2012-05-03 17:18:21
@alk alk self-assigned this Aug 23, 2015
@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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.

Reported by chappedm on 2012-05-04 16:01:54

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

Looks like 2.15 from libc6-2.15-0ubuntu10

Reported by cjaeger on 2012-05-04 16:14:45

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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.

Reported by chappedm on 2012-05-04 17:45:02

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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.

Reported by chappedm on 2012-05-15 17:26:42

  • Status changed: Accepted

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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

Reported by cjaeger on 2012-05-15 17:29:31

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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.

Reported by chappedm on 2012-05-15 19:41:16

@alk
Copy link
Contributor Author

alk commented Aug 23, 2015 

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

Reported by chappedm on 2012-11-03 15:04:21

@alk alk closed this as completed Aug 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alk alk

Labels
Priority-Medium Status-Duplicate Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@alk