tl;dr: could heaptrack pass signals along to the debugee? SUMMARY I'm trying to debug a program which runs in a container. This program normally runs as the entrypoint of the container, but now I run it inside heaptrack. To stop the container, the runtime sends SIGINT or SIGTERM to the primary process, which would cleanly shut down my program but does not get passed through the heaptrack shell script. Eventually the container runtime kills all the processes. As a result it looks like all the memory got leaked because the program did not go through a clean shutdown. The same would apply if running heaptrack from a systemd unit. STEPS TO REPRODUCE 1. Run `heaptrack /usr/bin/sleep 60` 2. Send SIGINT or SIGTERM to heaptrack OBSERVED RESULT heaptrack exits on SIGTERM but sleep is still running SIGINT seems to be ignored completely EXPECTED RESULT SIGTERM is sent to debugee SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian bookworm + heaptrack 1.4.0 from package, or heaptrack 1.5.0 compiled from source
I cannot reproduce this issue. First I did: ``` $ heaptrack sleep 5000 heaptrack output will be written to "/home/milian/projects/src/heaptrack/heaptrack.sleep.11782.zst" starting application, this might take some time... NOTE: heaptrack detected DEBUGINFOD_URLS but will disable it to prevent unintended network delays during recording If you really want to use DEBUGINFOD, export HEAPTRACK_ENABLE_DEBUGINFOD=1 ``` then I pressed `Ctrl+C` which stops the process then and opens up the UI. Sleep isn't running anymore at that point, only the heaptrack UI: ``` $ ps aux | grep sleep milian 11782 0.0 0.0 8228 4164 pts/1 S+ 09:41 0:00 /bin/sh /mnt/data1/milian/compiled/other/bin/heaptrack sleep 5000 milian 11912 5.1 0.6 5701264 228552 pts/1 Sl+ 09:41 0:00 /mnt/data1/milian/compiled/other/bin/heaptrack_gui /home/milian/projects/src/heaptrack/heaptrack.sleep.11782.zst milian 12035 0.0 0.0 6912 2420 pts/2 S+ 09:41 0:00 grep --colour sleep ```
(In reply to Milian Wolff from comment #1) > then I pressed `Ctrl+C` which stops the process then and opens up the UI. > Sleep isn't running anymore at that point, only the heaptrack UI: But then your signal went straight to sleep. If you send it to heaptrack, heaptrack will exit leaving the debuggee running. This is what happens if you run it in a container or from systemd. Not only is the child still running, the analysis is wrong because the child didn't get to run a clean shutdown.
ah, so: ``` $ heaptrack sleep 1000 & [1] 8817 heaptrack output will be written to "/tmp/heaptrack.sleep.8817.zst" starting application, this might take some time... NOTE: heaptrack detected DEBUGINFOD_URLS but will disable it to prevent unintended network delays during recording If you really want to use DEBUGINFOD, export HEAPTRACK_ENABLE_DEBUGINFOD=1 $ kill -SIGTERM 8817 ```
Hi, Is there any news on this issue? I needed to use heaptrack in a container again and ran into this same issue.
Looking at the wrapper script, I could simply set LD_PRELOAD and DUMP_HEAPTRACK_OUTPUT to get the raw output in my container environment. Anyway, I made the following modification to the code that starts the debuggee, and now it is passing the signals through: if [ -z "$debug" ] && [ -z "$pid" ]; then echo "starting application, this might take some time..." trap 'kill -TERM ${target_pid}' TERM trap 'kill -INT ${target_pid}' INT LD_PRELOAD="$LIBHEAPTRACK_PRELOAD${LD_PRELOAD:+:$LD_PRELOAD}" DUMP_HEAPTRACK_OUTPUT="$pipe" "$client" "$@" & target_pid=$! wait $target_pid EXIT_CODE=$? else