Re: command and doco for valgrind

[Nick Roberts]

 > 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.

Are you sure malloc returns NULL? Later you say:

> Given this, I can't seem to find a way to run "valgrind ./temacs" under GDB,
> and without that, how can I debug this?

I guess you've tried variants of "valgrind --gdb-attach=yes emacs". Thats what
my original post was about :-)

The problem, here, is that gdb attaches to emacs after it has called
memory_full.  However, if I do p lisp_malloc_loser, I get something like:

$1 = (void *) 0x418aad88

so it looks like val is *set* from this value to 0 in the loop:

      if ((char *) XCONS (tem) != (char *) val + nbytes - 1)
        {
          lisp_malloc_loser = val;
          free (val);
          val = 0;
        }

I don't know about x86 internals but is this away from the heap and somewhere
where shared libraries go? If I debug emacs directly, I get a lower address
value for val:

$1 = (void *) 0x8641e58


    Nick                                         http://www.nick.uklinux.net