On 01/05/17 12:41 AM, Matt Bohy wrote:
> Hello,
>
> I'm investigating a native memory leak in my company's Java web
> application. We are running a 32-bit JVM, version java-1.8.0_112.i586, on
> 64-bit CentOS 6.5 servers.
>
> I was hoping to use jemalloc to do profiling of the memory usage to
> identify the leak. I am trying to use libunwind (1.1) with jemalloc, but
> invariably upon starting up the application I get a segfault in the same
> function (access_mem) of libunwind:
>
> I have several hs_err_pid files (error logs from the JVM when it crashes),
> and several accompanying core dumps. They always point at line 150 of
> x86/Ginit.c:
>
> (gdb) l x86/Ginit.c:150
> 145 {
> 146 /* validate address */
> 147 const struct cursor *c = (const struct cursor *)arg;
> 148 if (c && c->validate && validate_mem(addr))
> 149 return -1;
> 150 *val = *(unw_word_t *) addr;
> 151 Debug (16, "mem[%x] -> %x\n", addr, *val);
> 152 }
> 153 return 0;
> 154 }
>
> Both jemalloc and libunwind were built from source on a 32-bit CentOS 6.5
> virtualbox VM. They are running on a 64-bit CentOS 6.5 virtualbox VM.
>
> Am I doing something wrong?
The 'validate_mem' call should be checking that it is safe to
dereference that addr, and prevent the segfault. AFAIK this is
usually caused by shared libraries being loaded / unloaded, or
sometimes by the heuristic guesses trying to follow the frame chain if
no dwarf unwind info exists (which is probably the case for Java).
I suggest checking that libunwind is building with
--enable-conservative-checks, and that validate_mem is working
reasonably for you (there are previous discussions about it on the
list)
_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
