Re: [Libunwind-devel] Inevitable segfault in access_mem on startup

[Dave Watson]

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)