1

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?

user3200145
  • 55
  • 3
  • Seems odd that `vsnprintf` would call `free`...can you figure out why/where it's doing that? – nneonneo Aug 29 '14 at 16:50
  • In the callstack, vsnprintf calls vprintf which actually calls the free. Also the address in the second free is NULL. This seems like a bug in libc. – user3200145 Aug 29 '14 at 18:01
  • 1
    Not a bug (you can call `free(0)` wherever you want, so `vsnprintf is completely entitled to), but something unnecessary that's making your life harder than it needs to be. – R.. GitHub STOP HELPING ICE Aug 29 '14 at 18:21

1 Answers1

2

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711