This is a segfault due to following a null pointer trying to find code to run (that is, during an instruction fetch).
If this were a program, not a shared library
Run addr2line -e yourSegfaultingProgram 00007f9bebcca90d (and repeat for the other instruction pointer values given) to see where the error is happening. Better, get a debug-instrumented build, and reproduce the problem under a debugger such as gdb.
Since it’s a shared library
You’re hosed, unfortunately; it’s not possible to know where the libraries were placed in memory by the dynamic linker after-the-fact. Reproduce the problem under gdb.
What the error means
Here’s the breakdown of the fields:
-
address(after theat) – the location in memory the code is trying to access (it’s likely that10and11are offsets from a pointer we expect to be set to a valid value but which is instead pointing to0) -
ip– instruction pointer, ie. where the code which is trying to do this lives -
sp– stack pointer -
error– An error code for page faults; see below for what this means on x86 (link)./* * Page fault error code bits: * * bit 0 == 0: no page found 1: protection fault * bit 1 == 0: read access 1: write access * bit 2 == 0: kernel-mode access 1: user-mode access * bit 3 == 1: use of reserved bit detected * bit 4 == 1: fault was an instruction fetch * bit 5 == 1: protection keys block access * bit 15 == 1: SGX MMU page-fault */