[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: valgrind emacs
From: |
Chong Yidong |
Subject: |
Re: valgrind emacs |
Date: |
Sat, 22 Mar 2008 17:47:10 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1.92 (gnu/linux) |
Neal Becker <address@hidden> writes:
> Anyone try valgrind on emacs? I get some errors:
> ==15930== Invalid free() / delete / delete[]
> ==15930== at 0x4A05AF7: realloc (vg_replace_malloc.c:306)
> ==15930== by 0x536A0D: xrealloc (alloc.c:788)
> ==15930== by 0x4F9DBF: enlarge_buffer_text (buffer.c:5095)
> ==15930== by 0x50458B: make_gap_larger (insdel.c:528)
> ==15930== by 0x46FE5B: alloc_destination (coding.c:1124)
> ==15930== by 0x4701B1: produce_chars (coding.c:6068)
> ==15930== by 0x4750ED: decode_coding (coding.c:6403)
> ==15930== by 0x476326: decode_coding_object (coding.c:7054)
> ==15930== by 0x476AF8: code_convert_string (coding.c:8281)
> ==15930== by 0x4DC268: main (emacs.c:555)
> ==15930== Address 0x256FB60 is not stack'd, malloc'd or (recently) free'd
I don't see how this code path could occur. This seems to be
complaining that b->text->beg in enlarge_buffer_text (buffer.c:5095)
is not a malloc'ed pointer. But this code path is only activated when
BUFFERP (coding->dst_object) in alloc_destination (buffer.c:1142).
Which means that we already have a valid buffer.
I haven't used valgrind before, so I don't know how reliable it is.
Does anyone know how easy it is to confuse it?
(I haven't studied the rest of the errors closely, but they seem to be
of the same variety.)