Re: command and doco for valgrind

[Eli Zaretskii]

> Date: 18 Jan 2004 16:17:11 +0200
> From: Eli Zaretskii <address@hidden>
> 
> > Date: Sat, 17 Jan 2004 23:38:58 +0000
> > From: Nick Roberts <address@hidden>
> > 
> > BTW I think valgrind could be a useful tool to debug some of Emacs crashes
> > (less frequent now) on x86 architectures. However, for some reason, it 
> > reports
> > a memory full message at start up, at the moment:
> > 
> > ==2466== Invalid free() / delete / delete[]
> > ==2466==    at 0x400263A8: free (vg_replace_malloc.c:231)
> > ==2466==    by 0x812A135: memory_full (alloc.c:478)
> > ==2466==    by 0x812A3E8: lisp_malloc (alloc.c:623)
> > ==2466==    by 0x812BA07: allocate_vectorlike (alloc.c:2505)
> > ==2466==    Address 0x83CCE60 is not stack'd, malloc'd or free'd
> > emacs: Memory exhausted--use M-x save-some-buffers then exit and restart 
> > Emacs
> 
> FWIW, this problem is documented in the valgrind's docs.
> 
> I'll try to look into this and see what I find.

After futzing with this for a while, all I can say is "weird".  The
above problem happens because lisp_malloc calls malloc to allocate a
Lisp vector during startup, and malloc returns NULL.  Emacs then
rightfully decides that there's not enough memory and that therefore
it cannot continue its startup, and it exits.  (The mesage about
free'in memory that wasn't malloc'ed seems to be a separate problem.)

Why malloc returns NULL is a mystery.  Emacs on GNU/Linux (the only
platform supported by valgrind) uses malloc from glibc, so I cannot
easily look into that, as I don't have the sources that correspond to
the particular version of glibc used by that box (fencepost.gnu.org, a
Debian system).  Perhaps someone who has the sources could do that.

Moreover, even temacs appears to crash under valgrind: try

  valgrind ./temacs

or

  valgrind ./temacs -l loadup

They both crash with SIGSEGV in some way or another.  "./temacs"
without valgrind works as expected, of course.

Did I say it's weird?

I think someone who knows more about valgrind's messing with the
instruction stream should debug this.  Since this problem happens only
under valgrind, and valgrind doesn't run the original code of the
Emacs binary, but instead modifies the instruction stream in many ways
and executes the modified code on a synthetic CPU that is part of
valgrind's core, it's not even clear to me how to debug such problems
with GDB.

Sorry.