segfault on exiting trivial program linked to dmalloc

Bug #971174 reported by Martin Pool
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
dmalloc (Ubuntu)
Triaged
High
Unassigned

Bug Description

see <http://<email address hidden>/msg13281.html> for context:

This trivial program:

#include <dmalloc.h>

int main (int argc, char *argv[]) {
        malloc(1);
        return 0;
}

compiled with

gcc -o tst tst.c -ldmalloc

crashes on exit:

#5 0x00007ffff7af11fa in ?? () from /usr/lib/libdmalloc.so.5
#6 0x00007ffff7af1a72 in dmalloc_free () from /usr/lib/libdmalloc.so.5
#7 0x00007ffff7771ba4 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007ffff7831580 in __vsnprintf_chk () from
/lib/x86_64-linux-gnu/libc.so.6
#9 0x00007ffff7aebf7e in loc_vsnprintf () from /usr/lib/libdmalloc.so.5
#10 0x00007ffff7aec022 in loc_snprintf () from /usr/lib/libdmalloc.so.5
#11 0x00007ffff7af0c48 in _dmalloc_die () from /usr/lib/libdmalloc.so.5
#12 0x00007ffff7af11fa in ?? () from /usr/lib/libdmalloc.so.5
#13 0x00007ffff7af1a72 in dmalloc_free () from /usr/lib/libdmalloc.so.5
#14 0x00007ffff7771ba4 in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x00007ffff7831580 in __vsnprintf_chk () from
/lib/x86_64-linux-gnu/libc.so.6
#16 0x00007ffff7aebf7e in loc_vsnprintf () from /usr/lib/libdmalloc.so.5
#17 0x00007ffff7aec022 in loc_snprintf () from /usr/lib/libdmalloc.so.5

I guess dmalloc is out of date with something that changed in libc.

I tested on Precise; apparently it is also broken on Oneiric.

The user reports upstream is unresponsive.

Perhaps dmalloc should be removed from Precise, if it's not too late?

Martin Pool (mbp)
Changed in dmalloc (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Jason (reeot) wrote :

The bug is related to the call to libc's vsnprintf in compat.c on line 145.. Commenting out all the calls to vsnprintf and leaving it to use the string copy works fine on the tests I have run.

Revision history for this message
Corry Lazarowitz (corryl) wrote :

The workaround destroys the output of dmalloc, so I see things like
Error: %s (err %d)
and
%ld: %lu: Warning tried to free (0) from '%s'
%ld: %lu: error details: %s
%ld: %lu: pointer '%#lx' from '%s' prev access '%s'

none of which is particularly usefull, and I might as well not be using dmalloc at this point.

Here's the relevant stack trace info...

#0 _IO_vfprintf_internal
#1 _IO_vfprintf
#2 loc_vsnprintf
#3 loc_snprintf
#4 _dmalloc_vmessage
#5 dmalloc_message
#6 dmalloc_error
#7 dmalloc_in
#8 dmalloc_free
#9 free ()
.
. (pattern above repeats....a lot....)
.
#29222 free
#29223 _IO_vfprintf_internal
#29224 _IO_vfprintf
#29225 loc_vsnprintf
#29226 loc_snprintf
#29227 dmalloc_chunk_desc_pnt
#29228 dmalloc_chunk_free
#29229 dmalloc_free
#29230 free
#29231 _IO_vfprintf_internal
#29232 buffered_vfprintf
#29233 _IO_vfprintf_internal
#29234 ___vfprintf_chk
#29235 xmlGenericErrorDefaultFunc

was this perhaps fixed in a newer ubuntu release since I see the last comment was June 2012?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.