Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>We once had a bug which eluded all of the regular techniques, valgrind, purify etc. The crash only ever happened on machines with lots of memory and only on large input data sets.</p> <p>Eventually we tracked it down using debugger watch points. I'll try to describe the procedure here:</p> <p>1) Find the cause of the failure. It looks from your example code, that the memory for "exampleString" is being corrupted, and so cannot be written to. Let's continue with this assumption.</p> <p>2) Set a breakpoint at the last known location that "exampleString" is used or modified without any problem.</p> <p>3) Add a watch point to the data member of 'exampleString'. With my version of g++, the string is stored in <code>_M_dataplus._M_p</code>. We want to know when this data member changes. The GDB technique for this is:</p> <pre><code>(gdb) p &amp;exampleString._M_dataplus._M_p $3 = (char **) 0xbfccc2d8 (gdb) watch *$3 Hardware watchpoint 1: *$3 </code></pre> <p>I'm obviously using linux with g++ and gdb here, but I believe that memory watch points are available with most debuggers.</p> <p>4) Continue until the watch point is triggered:</p> <pre><code>Continuing. Hardware watchpoint 2: *$3 Old value = 0xb7ec2604 "" New value = 0x804a014 "" 0xb7e70a1c in std::string::_M_mutate () from /usr/lib/libstdc++.so.6 (gdb) where </code></pre> <p>The gdb <code>where</code> command will give a back trace showing what resulted in the modification. This is either a perfectly legal modification, in which case just continue - or if you're lucky it will be the modification due to the memory corruption. In the latter case, you should now be able to review the code that is <em>really</em> causing the problem and hopefully fix it.</p> <p>The cause of our bug was an array access with a negative index. The index was the result of a cast of a pointer to an 'int' modulos the size of the array. The bug was missed by valgrind et al. as the memory addresses allocated when running under those tools was never "<code>&gt; MAX_INT</code>" and so never resulted in a negative index.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload