6

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

Botje
  • 26,269
  • 3
  • 31
  • 41
  • 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. – user13793645 Jun 22 '20 at 17:23
  • How are you invoking jeprof? – Botje Jun 23 '20 at 06:33
  • jeprof --show_bytes --gif /path/to/jvm/bin/java jeprof*.heap > /tmp/app-profiling.gif – user13793645 Jun 24 '20 at 07:08
  • 2
    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` – Cristian Oct 08 '20 at 03:34

0 Answers0