title: Understanding GDB and Segfault Messages
body: <p>I was recently debugging an application that was segfaulting on a regular basis--I solved the problem, which was relatively mundane (reading from a null pointer), but I have a few residual questions I've been unable to solve on my own.</p>
  
  <p>The gdb stack trace began like this in most cases:</p>
  
  <pre><code>0x00007fdff330059f in __strlen_sse42 () from /lib64/libc.so.6
  </code></pre>
  
  <p>Using information from /proc/[my proc id]/maps to attain the base address of the shared library, I could see that the problem occurred at the same instruction of the shared library--at instruction 0x13259f, which is </p>
  
  <pre><code>pcmpeqb (%rdi),%xmm1 (gdb)
  </code></pre>
  
  <p>So far, so good.  But then, the OS (linux) would also write out an error message to /var/logs/messags, that looks like this</p>
  
  <pre><code>[3540502.783205] node[24638]: segfault at 0 ip 00007f8abbe6459f sp 00007fff7bf2f148 error 4 in libc-2.12.so[7f8abbd32000+189000]
  </code></pre>
  
  <p>Which confuses me.  On the one hand, the kernel correctly identifies the fault (a user-mode protection fault), and, by subtracting the base address of the shared library from the instruction pointer, we arrive at the same relative offset--0x13259f--as we do by gdb.  But the library the kernel identifies is different, the address of the instruction is different, and the function and instruction within that library is different.  That is, the instruction within libc-2-12.so is</p>
  
  <pre><code>0x13259f &lt;__memset_sse2+911&gt;:  movdqa %xmm0,-0x43(%edx)
  </code></pre>
  
  <p>So, my question is, how can gdb and the kernel message agree on the type of fault, and on the offset of the instruction relative to the base address of the shared library, but disagree on the address of the instruction pointer and the shared library being used?</p>