Are there standard workarounds for dmalloc's assumptions on vsnprintf?

Question

I'm trying to use dmalloc version 5.5.2 and glibc 2.17.

Linking in dmalloc always causes a segfault.

Debugging, I found that dmalloc calls vsnprintf(...) when it wants to format a helpful debugging message. Unfortunately vsnprintf(..) itself calls free(), so the reason for the segmentation fault is a recursion. free() calls vsnprintf(), vsnprintf() calls free(), etc, etc until we segfault with a gigantic stack trace.

One can quickly fix this by undefining HAVE_VSNPRINTF and HAVE_VPRINTF, but then the debugging messages are missing key information.

I've hacked my own solution to this problem by using an ancient implementation of vsnprintf(...) that does not allocate memory, but it is hard to believe there's not already a good solution out there.

Is there a standard way to solve this problem with dmalloc?

Answer 1

Since you've found that the offending call is a useless one with a null argument, the simplest workaround seems to be adding if (!p) return; at the beginning of dmalloc's free.