version 1.0, build on ubuntu 16.04 When we run heaptrack in "attach to process" mode, the breaking (with Ctrl-C or kill) the analysis leads to not-full cleanup. Steps to reproduce: 1) Run some application 2) Take it PID 3) Run "heaptrack -p PID" from terminal 4) After "injection finished" message press Ctrl-C (break) or kill heaptrack process. Expected behavior: Heaptrack stops it work and perform all cleanup actions. Real behavior: Heaptrack stops it work and NOT perform cleanup actions. In particular the "heaptrack_interpret" process is still running and "breaks" next heaptrack runs. After the killing this "zombie" the attached process also died with error.
hm true: Thread 4 "kwrite" received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7f34a864f700 (LWP 17194)] 0x00007f34ca43a54d in write () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007f34ca43a54d in write () from /usr/lib/libc.so.6 #1 0x00007f34ca3d1867 in _IO_new_file_write () from /usr/lib/libc.so.6 #2 0x00007f34ca3d0bb2 in new_do_write () from /usr/lib/libc.so.6 #3 0x00007f34ca3d2939 in __GI__IO_do_write () from /usr/lib/libc.so.6 #4 0x00007f34ca3d1f06 in __GI__IO_file_xsputn () from /usr/lib/libc.so.6 #5 0x00007f34ca3a5ea6 in vfprintf () from /usr/lib/libc.so.6 #6 0x00007f34ca3ae1d7 in fprintf () from /usr/lib/libc.so.6 #7 0x00007f34b004590b in (anonymous namespace)::HeapTrack::writeTimestamp (this=<synthetic pointer>) at /home/milian/projects/src/heaptrack/src/track/libheaptrack.cpp:315 #8 (anonymous namespace)::HeapTrack::LockedData::<lambda()>::operator() (__closure=<optimized out>) at /home/milian/projects/src/heaptrack/src/track/libheaptrack.cpp:489 #9 std::_Bind_simple<(anonymous namespace)::HeapTrack::LockedData::LockedData(FILE*, heaptrack_callback_t)::<lambda()>()>::_M_invoke<> (this=<optimized out>) at /usr/include/c++/6.3.1/functional:1391 #10 std::_Bind_simple<(anonymous namespace)::HeapTrack::LockedData::LockedData(FILE*, heaptrack_callback_t)::<lambda()>()>::operator() (this=<optimized out>) at /usr/include/c++/6.3.1/functional:1380 #11 std::thread::_State_impl<std::_Bind_simple<(anonymous namespace)::HeapTrack::LockedData::LockedData(FILE*, heaptrack_callback_t)::<lambda()>()> >::_M_run(void) (this=<optimized out>) at /usr/include/c++/6.3.1/thread:197 #12 0x00007f34cacd558f in std::execute_native_thread_routine (__p=0x22bc420) at /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/thread.cc:83 #13 0x00007f34c8220454 in start_thread () from /usr/lib/libpthread.so.0 #14 0x00007f34ca4477df in clone () from /usr/lib/libc.so.6
Git commit 932defacaa604a3359d61a65397c8fa319c1f347 by Milian Wolff. Committed on 05/03/2017 at 21:47. Pushed by mwolff into branch '1.0'. Improve cleanup after detaching heaptrack We now stop heaptrack explicitly via GDB before breaking the pipe. This improves the stability of the unload process of heaptrack after runtime-injection. It is still somewhat shaky though. I still see crashes on shutdown of the debuggee now, long after heaptrack was stopped. Similarly, I see tons of issues when I try to unload libheaptrack_inject via __libc_dlclose, so I'm keeping the library loaded for now. I've added an explicit warning now to the `-p` option, saying that runtime-attaching is unstable and can crash the debuggee. M +12 -0 src/track/heaptrack.sh.cmake M +16 -2 src/track/libheaptrack.cpp https://commits.kde.org/heaptrack/932defacaa604a3359d61a65397c8fa319c1f347