Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all, note that the backtrace contains a call <code>malloc_printerr</code>. The function will write the reason to standard error, so remember to have it captured!</p> <p>Now whether it's mismatched new/delete types, double-delete or invalid pointer altogether, the actual bug happens long before the delete that actually detects it. So gdb is not going to be of much use. You will have to log anything that happens to the relevant pointer and dig up when it went wrong.</p> <ul> <li>If it is invalid pointer altogether, it would be either uninitialized memory or buffer overrun overwriting it. Review that all objects have correct constructors that zero out any pointer that might be involved. Either problem can also be caught with <a href="http://valgrind.org/" rel="nofollow">valgrind</a>, buffer overruns can also be caught with less overhead (but less precision) using <a href="http://duma.sourceforge.net/" rel="nofollow">DUMA library</a> or <a href="http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging" rel="nofollow">mudflap</a> (shipped with gcc).</li> <li>If it's double-delete, review that you zero out any involved pointer after deleting it except if in a destructor (and if you are deleting it in destructor, make sure you initialized it in constructor). Add log messages for all operations on the involved pointer and when it crashes, trace back in the log where the pointer appears to have been resurrected. You can also try to do that for invalid pointer.</li> <li>If it's mismatched <code>[]</code>, make sure you always delete with <code>[]</code> when you allocated with <code>[]</code> and never otherwise and make sure you are always deleting complete type (C++ accepts deleting incomplete type and it's undefined behaviour).</li> <li>Any of the above can also be secondary effect of not properly calling destructors of any object holding the involved pointer. Failing to call destructor might be reason of deleting pointer with incorrect type, deleting pointer to incomplete type or mismatching <code>[]</code> on new and delete. In addition to review, add log to any constructors and destructors that might be relevant and check in the log that they are properly matched up.</li> </ul> <p>Don't forget to always log the pointer value so you can actually match the entries. You'll also probably need to write some scripts for analyzing the log (find the entries that are mismatched). And have enough space for it; it's rather easy to generate many <b>giga</b>bytes of log this way.</p> <p>Once you narrow down few operations that are suspect, you might need to write backtrace into the logs. Look at the <a href="http://linux.die.net/man/3/backtrace" rel="nofollow">backtrace(3)</a> library function or the <a href="http://www.nongnu.org/libunwind/" rel="nofollow">libunwind</a>.</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.
    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