jemalloc / jeprof shows addresses not function names based on lg_prof_interval

Question

I'm trying to debug a memory leak in some vendor-provided JNI/native code and, like many people it seems, started here: https://technology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/

I've found if I run:

export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17

then run my application, and then run the jeprof ... command to generate the .gif I can see the JNI function names causing the leak (which is good!).

I tried changing lg_prof_interval:30 to lg_prof_interval:25 which produces .heap files much more frequently, but I've found the JNI function names I mentioned previously have been replaced by addresses (0x000123...). I haven't made any other changes, and have double- and triple- checked that running with lg_prof_interval:30 lets me see the function names in the resulting .gifs, but lg_prof_interval:25 doesn't.

The reason I want to use lg_prof_interval:25 is because I need to re-run the profiling with a slimmed-down version of the application suffering the memory leaks, but I fear it will take forever to use 2^30 bytes so will never see a .heap file.

I've seen similar questions where the answers have suggested installing a dbg version of the jdk, yet I struggle to see why this could be the cause in my case.

Many thanks in advance.

TLDR: can see function names with lg_prof_interval:30 but not lg_prof_interval:25

Brandt

My guess is that with :30 the program has been alive long enough for the method names to have been 'cached' somewhere, but not with :25 which starts dumping .heap files almost straight away, but that is purely speculation. – Brandt

How are you invoking jeprof? – Codicil

jeprof --show_bytes --gif /path/to/jvm/bin/java jeprof*.heap > /tmp/app-profiling.gif – Brandt

This happened to me today. It turns out that doing jeprof*.heap is a bad idea: it will include all profiles by ALL applications that happen to use jemalloc. In my case, I noticed files that look like jeprof.43312.xxxx.heap where as the PID of the application was different. So it was mixing everything up. The right way to run this command is using jeprof.PID_OF_THE_APP.*.heap – Axon

did you found the solution? – Baht

Answer 1

Today I am facing the same issue when using jeprof to analysis the rust dump file, for me. I am compile the rust in Debian bulleye and run the jeprof command in CentOS 8, generate the pdf did not contains the method name, only contains address. using the same operation system when compile and using jeprof fixed this issue.

Baht