On Mon, 2 Feb 2009, Miller Puckette wrote:

I don't know whether you use Valgrind, but I would very much recommend it. It runs your programme in a sort of emulator that checks all memory accesses. It can help you find a lot more bugs than gdb can. It can tell you whether it's an uninitialised pointer, dangling pointer, double free, buffer overflow, etc., and give you both a backtrace of the problem and a backtrace of the related malloc (!!!).

The main downside is that there can be a lot of false positives, so you have to learn to recognise those as such and perhaps have to make yourself a "suppression file" to hide them.

The other main downside is that it can't find most stack-related problems because that would require the collaboration of the compiler. But most of the trickiest bugs tend to be malloc-related rather than stack-related.

Of course you can't debug everything with valgrind and this is why I also use gdb.

I wish gdb were more customisable, so that for example it could print a t_symbol * like:

gensym("hello")

for example. it could save a lot of time.