SUMMARY DHAT doesn't produce any output or produce a log file when running on the rust compiler. STEPS TO REPRODUCE 1. cargo new valgrind_is_broken --bin 2. cd valgrind_is_broken 3. valgrind --tool=dhat cargo build OBSERVED RESULT ``` [skainswo@recycle valgrind_is_broken]$ valgrind --tool=dhat cargo build ==16455== DHAT, a dynamic heap analysis tool ==16455== Copyright (C) 2010-2018, and GNU GPL'd, by Mozilla Foundation ==16455== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==16455== Command: cargo build ==16455== Compiling valgrind_is_broken v0.1.0 (/homes/gws/skainswo/valgrind_is_broken) Finished dev [unoptimized + debuginfo] target(s) in 1.10s [skainswo@recycle valgrind_is_broken]$ ``` and no dhat.out.<pid> file is produced. EXPECTED RESULT Output like ``` ==16841== ==16841== Total: 57,140 bytes in 45 blocks ==16841== At t-gmax: 55,871 bytes in 39 blocks ==16841== At t-end: 19,921 bytes in 10 blocks ==16841== Reads: 7,050 bytes ==16841== Writes: 6,858 bytes ==16841== ==16841== To view the resulting profile, open ==16841== file:///usr/local/libexec/valgrind/dh_view.html ==16841== in a web browser, click on "Load..." and then select the file ==16841== /homes/gws/skainswo/deleteme/dhat.out.16841 ==16841== Scroll to the end the displayed page to see a short ==16841== explanation of some of the abbreviations used in the page. ``` and a log file like `dhat.out.16841` to be produced. SOFTWARE/OS VERSIONS ``` [skainswo@recycle deleteme]$ uname -a Linux recycle.cs.washington.edu 4.14.125-1.el7.retpoline.x86_64 #1 SMP Tue Jun 11 14:07:55 PDT 2019 x86_64 x86_64 x86_64 GNU/Linux ``` ADDITIONAL INFORMATION Here's the verbose output: ``` [skainswo@recycle deleteme]$ /usr/bin/valgrind -v --tool=dhat cargo build ==17433== DHAT, a dynamic heap analysis tool ==17433== Copyright (C) 2010-2018, and GNU GPL'd, by Mozilla Foundation ==17433== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info ==17433== Command: cargo build ==17433== --17433-- Valgrind options: --17433-- -v --17433-- --tool=dhat --17433-- Contents of /proc/version: --17433-- Linux version 4.14.125-1.el7.retpoline.x86_64 (jrp@lida.cs.washington.edu) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Tue Jun 11 14:07:55 PDT 2019 --17433-- --17433-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-ssse3-avx --17433-- Page sizes: currently 4096, max supported 4096 --17433-- Valgrind library directory: /homes/gws/skainswo/bin/valgrind/lib/valgrind --17433-- Reading syms from /homes/gws/skainswo/.cargo/bin/cargo --17433-- Warning: cross-CU LIMITATION: some inlined fn names --17433-- might be shown as UnknownInlinedFun --17433-- Reading syms from /usr/lib64/ld-2.17.so --17433-- Reading syms from /homes/gws/skainswo/bin/valgrind/lib/valgrind/dhat-amd64-linux --17433-- object doesn't have a dynamic symbol table --17433-- Scheduler: using generic scheduler lock implementation. ==17433== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-17433-by-skainswo-on-recycle.cs.washington.edu ==17433== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-17433-by-skainswo-on-recycle.cs.washington.edu ==17433== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-17433-by-skainswo-on-recycle.cs.washington.edu ==17433== ==17433== TO CONTROL THIS PROCESS USING vgdb (which you probably ==17433== don't want to do, unless you know exactly what you're doing, ==17433== or are doing some strange experiment): ==17433== /homes/gws/skainswo/bin/valgrind/lib/valgrind/../../bin/vgdb --pid=17433 ...command... ==17433== ==17433== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==17433== /path/to/gdb cargo ==17433== and then give GDB the following command ==17433== target remote | /homes/gws/skainswo/bin/valgrind/lib/valgrind/../../bin/vgdb --pid=17433 ==17433== --pid is optional if only one valgrind process is running ==17433== --17433-- Reading syms from /homes/gws/skainswo/bin/valgrind/lib/valgrind/vgpreload_core-amd64-linux.so --17433-- Reading syms from /homes/gws/skainswo/bin/valgrind/lib/valgrind/vgpreload_dhat-amd64-linux.so --17433-- Reading syms from /usr/lib64/libdl-2.17.so --17433-- Reading syms from /usr/lib64/librt-2.17.so --17433-- Reading syms from /usr/lib64/libpthread-2.17.so --17433-- Reading syms from /usr/lib64/libgcc_s-4.8.5-20150702.so.1 --17433-- object doesn't have a symbol table --17433-- Reading syms from /usr/lib64/libc-2.17.so --17433-- Reading syms from /usr/lib64/libm-2.17.so --17433-- REDIR: 0x56f1a90 (libc.so.6:malloc) redirected to 0x4c2802d (malloc) --17433-- REDIR: 0x56f1f90 (libc.so.6:realloc) redirected to 0x4c2a45d (realloc) --17433-- REDIR: 0x56f1eb0 (libc.so.6:free) redirected to 0x4c291da (free) --17433-- REDIR: 0x56f24b0 (libc.so.6:calloc) redirected to 0x4c2a264 (calloc) --17433-- REDIR: 0x56f4000 (libc.so.6:posix_memalign) redirected to 0x4c2a6e4 (posix_memalign) Finished dev [unoptimized + debuginfo] target(s) in 0.03s [skainswo@recycle deleteme]$ ```
That looks like you ran valgrind on cargo rather than on the compiler? or does the compiler run as part of cargo? Does tracing into children with --trace-children=yes help?
(In reply to Tom Hughes from comment #1) > That looks like you ran valgrind on cargo rather than on the compiler? or > does the compiler run as part of cargo? > > Does tracing into children with --trace-children=yes help? I tried running `cargo build`, `cargo rustc`, and `rustc`, but I think they must all spin off children because `--trace-children=yes` seems to work! Perhaps valgrind could detect children and add a warning pointing users to this flag? Otherwise it can be quite confusing why there's no output whatsoever. In fact I guess I'm still confused why DHAT didn't produce any output for the parent process (cargo).
Well yes they will all spin off children because rustc is a separate program to cargo - it's like tracing make and it not following over the exec when it runs gcc to do the actual compile. Note that --trace-children is slightly misnamed because it doesn't control tracing over fork (fork is always followed) but rather it controls whether an exec of a new executable is followed.