title: Investigating a bad free() pointer reference
body: <p>My program is crashing badly in an unitary test, due to a free() call to a bad pointer, with this error message:</p>
  
  <pre><code>*** glibc detected *** /home/user/main.out: free(): invalid pointer: 0x006d0065 ***
  </code></pre>
  
  <p>The code looks roughly like this:</p>
  
  <pre><code>// constructor is MyObj( const std::string &amp; ) 
  // and copies the string in its own std:string member
  MyObject *obj = new MyObject("some string arg");
  if(obj-&gt;isValid)
  {
     log("Success\n");
  }
  delete obj; // if I remove this, the program doesn't crash...
  </code></pre>
  
  <p>My investigations have gone through this: </p>
  
  <ol>
  <li><p>I tried to trace the pointers I create and free, but it occurs in a different address space, I get (successful) deletions like this: <code>Delete buffer @0x850ed0</code>. So I suspect something's trying to free a static char pointer. Also, the address stays the same over several attempts, which comforts me in this predicate.</p></li>
  <li><p>I can't use GDB because the platform I'm using seems to bail out:</p>
  
  <p><code>Program received signal SIGABRT, Aborted.</code><br>
  <code>[Switching to Thread 0x344314e8 (LWP 1443)]</code><br>
  <code>0x2a3dd658 in raise () from /lib/libc.so.6</code><br>
  <code>(gdb) bt</code><br>
  <code>#0  0x2a3dd658 in raise () from /lib/libc.so.6</code><br>
  <code>#1  0x2a3dea2c in abort () from /lib/libc.so.6</code><br>
  <code>Backtrace stopped: frame did not save the PC</code>  </p></li>
  <li><p>I tried to use hexdump to dump the address in the program on which the free() fails with this: <code>hexdump -C ~/main.out -s 0x6d0000 -n 2000</code></p>
  
  <p>It gives me this (fault is <code>free(0x6d0065)</code>):</p>
  
  <p><code>006d0060  e8 32 06 00 2c e6 02 5f  5a 4e 4b 53 73 34 66 69  |.2..,.._ZNKSs4fi|</code>
  <code>006d0070  6e 64 45 63 6a 00 ab 00  00 00 01 3e 58 00 00 1d  |ndEcj......&gt;X...|</code></p>
  
  <p>Which looks like a std::string function, which is quite strange...
  I figured this might be a bad use of hexdump, since the memory gets relocated when the program is loaded into memory. </p></li>
  <li><p>I tried <code>readelf ~/main.out -a | grep 6d0065</code> to no avail as well (gives no hit)</p></li>
  </ol>
  
  <p>I'm not a pro on debugging in these conditions; do you have any idea of how I could get what this address means to the program?</p>
  
  <p><strong>Edit:</strong>  </p>
  
  <ul>
  <li><p>The program runs on an embedded platform (SH4); which is not supported by valgrind (very sadly...).</p></li>
  <li><p>Some more details on what this class does: it uses the <a href="http://curl.haxx.se/libcurl/" rel="nofollow">CUrl library</a> to retrieve an XML file on the internet, then proceeds to parse it with the <a href="http://code.google.com/p/pugixml/" rel="nofollow">pugixml</a> library. </p></li>
  </ul>