title: Analyzing core dump with stack corrupted
body: <p>I am currently trying to debug a core in my C++ app. The customer has reported a <code>SEGFAULT</code> core with following thread list:</p>
  
  <pre><code>...Other threads go above here
    3 Thread 0xf73a2b70 (LWP 2120)  0x006fa430 in __kernel_vsyscall ()
    2 Thread 0x2291b70 (LWP 2212)  0x006fa430 in __kernel_vsyscall ()
  * 1 Thread 0x218fb70 (LWP 2210)  0x00000000 in ?? ()
  </code></pre>
  
  <p>The thing that puzzles me is the thread that crashed which points <code>0x00000000</code>. If I try to inspect backtrace, I get:</p>
  
  <pre><code>Thread 1 (Thread 0x1eeeb70 (LWP 27156)):
  #0  0x00000000 in ?? ()
  #1  0x00281da7 in SomeClass1::_someKnownMethod1 (this=..., elem=...) at path_to_cpp_file:line_number
  #2  0x0028484d in SomeClass2::_someKnownMethod2 (this=..., stream=..., stanza=...) at path_to_cpp_file:line_number
  #3  0x002958b2 in SomeClass3::_someKnownMethod3 (this=..., stream=..., elem=...) at path_to_cpp_file:line_number
  </code></pre>
  
  <p>I appologize about redaction - a limitations of NDA.</p>
  
  <p>Obviously, the top frame is quite unknown. My first guess was that <code>PC</code> register got corrupted by some stack overwrite. </p>
  
  <p>I have tried reproducting the issue in my local deployment by supplying the same call that was seen in <code>Frame #1</code> but the crash never happened.</p>
  
  <p>It is a known fact that these cores are very difficult to debug? But does anyone has some hint on what to try out?</p>
  
  <h2>Update</h2>
  
  <pre><code>   0x00281d8b &lt;+171&gt;:   mov    edx,DWORD PTR [ebp+0x8]
     0x00281d8e &lt;+174&gt;:   mov    ecx,DWORD PTR [ebp+0xc]
     0x00281d91 &lt;+177&gt;:   mov    eax,DWORD PTR [edx+0x8]
     0x00281d94 &lt;+180&gt;:   mov    edx,DWORD PTR [eax]
     0x00281d96 &lt;+182&gt;:   mov    DWORD PTR [esp+0x8],ecx
     0x00281d9a &lt;+186&gt;:   mov    ecx,DWORD PTR [ebp+0x8]
     0x00281d9d &lt;+189&gt;:   mov    DWORD PTR [esp],eax
     0x00281da0 &lt;+192&gt;:   mov    DWORD PTR [esp+0x4],ecx
     0x00281da4 &lt;+196&gt;:   call   DWORD PTR [edx+0x14]
  =&gt; 0x00281da7 &lt;+199&gt;:   mov    ebx,DWORD PTR [ebp-0xc]
     0x00281daa &lt;+202&gt;:   mov    esi,DWORD PTR [ebp-0x8]
     0x00281dad &lt;+205&gt;:   mov    edi,DWORD PTR [ebp-0x4]
     0x00281db0 &lt;+208&gt;:   mov    esp,ebp
     0x00281db2 &lt;+210&gt;:   pop    ebp
     0x00281db3 &lt;+211&gt;:   ret
     0x00281db4 &lt;+212&gt;:   lea    esi,[esi+eiz*1+0x0]
  </code></pre>
  
  <p>... should have been the one from <code>Frame #0</code>, but from the disassembly this makes little sense. It is like the program has crashed while returning from <code>Frame #1</code>, but why am I seeing the invalid <code>Frame #0</code>? Or does this frame tear down part belongs to a function <code>onPacket</code>?</p>
  
  <h2>Update #2:</h2>
  
  <pre><code>(gdb) p/x $edx
  $5 = 0x1deb664
  (gdb) print _listener
  $6 = (jax::MyClass &amp;) @0xf6dbf6c4: {_vptr.MyClass= 0x1deb664}
  </code></pre>