search

chencl / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

x86_64 trouble with libunwind #66

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 

Having read the INSTALL and README file, x86_64 seems to be difficult to
get working in a stable manner.

I tried all the libunwind, the -Wl,-fno-omit-frame-pointer,-leh_gcc, etc.
flags but it reliably crashes whenever I want to use the CPU or heap profiler.

Given the increasing popularity of x86_64 users (especially those who are
actually developers and require performance tuning of their applications),
can you please consider putting more effort into getting the x86_64
usability to a higher level?

Thanks a lot!

What version of the product are you using? On what operating system?

Ubuntu 08.04 x86_64.

Original issue reported on code.google.com by nowo...@gmail.com on 30 Jun 2008 at 10:06

GoogleCodeExporter commented 9 years ago 
Here is a backtrace:

#0  0x00000033f260ef1d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00000033f260989d in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x00007f4690e85b45 in get_rs_cache (as=0x7f4690eac0b0 <local_addr_space>, 
saved_maskp=<optimized out>) at 
../../src/third_party/libunwind/exported/src/dwarf/Gparser.c:543
#3  _ULx86_64_dwarf_find_save_locs (c=0x7f468c113748) at 
../../src/third_party/libunwind/exported/src/dwarf/Gparser.c:875
#4  0x00007f4690e87699 in _ULx86_64_dwarf_step (c=0x7f468c113748) at 
../../src/third_party/libunwind/exported/src/dwarf/Gstep.c:34
#5  0x00007f4690e8d7e6 in _ULx86_64_step (cursor=0x7f468c113748) at 
../../src/third_party/libunwind/exported/src/x86_64/Gstep.c:71
#6  0x00007f4690faf8bd in GetStackTrace_libunwind(void**, int, int) () from 
out/Release.gn/libtcmalloc.so
#7  0x00007f4690faf15b in GetStackTrace(void**, int, int) () from 
out/Release.gn/libtcmalloc.so
#8  0x00007f4690fa4c81 in MallocHook_GetCallerStackTrace () from 
out/Release.gn/libtcmalloc.so
#9  0x00007f4690fab9bf in NewHook () from out/Release.gn/libtcmalloc.so
#10 0x00007f4690fa46b8 in MallocHook::InvokeNewHookSlow(void const*, unsigned 
long) () from out/Release.gn/libtcmalloc.so
#11 0x00007f4690fb20f7 in tc_new () from out/Release.gn/libtcmalloc.so
#12 0x00007f4690f44d88 in std::__1::basic_string<char, 
std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, 
unsigned long) () from out/Release.gn/libc++.so
...

I will try a safeness helper soon.

Original comment by abys...@gmail.com on 13 Nov 2014 at 10:53

GoogleCodeExporter commented 9 years ago 
It's backtrace of just one thread. There probably should more more. May I have 
backtraces of all threads ?

Original comment by alkondratenko on 13 Nov 2014 at 3:38

GoogleCodeExporter commented 9 years ago 
Actually, there is only one thread:

(gdb) info thr
  Id   Target Id         Frame 
* 1    Thread 0x7f90070b9700 (LWP 31160) "exec_name" 0x00000033f260ef1d in 
__lll_lock_wait () from /lib64/libpthread.so.0

It happens just after a call to fork() and almost before a call to exec(). 
Possibly, the problem is somehow related with a fact that a parent process is 
multi-threaded.

Original comment by abys...@gmail.com on 13 Nov 2014 at 5:53

GoogleCodeExporter commented 9 years ago 
Ok. Then it's near-unfixable effect of forking without exec-ing.

When you fork in multi-threaded program, various threads might be holding locks 
at the time of forking. So you child inherits memory image that has locks taken 
without anybody left to unlock them.

So kind of workaround for this is via pthread_atfork but it'll have to manually 
deal with all locks that might be taken at fork time.

I think in the end it's not a good idea in principle to fork multithreaded 
program without intention of immediately calling exec.

If I'm right, then unwind safeness helper will not be able to help.

Original comment by alkondratenko on 13 Nov 2014 at 6:24

GoogleCodeExporter commented 9 years ago 
Thank you. I found a couple of non-"async-signal-safe" calls in between fork() 
and exec(). One of them was a heap allocation. My problem has gone, and for 
sure doesn't relate to this issue anymore.

Original comment by abys...@gmail.com on 13 Nov 2014 at 8:31