bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stack overflow while using sml-mode.el


From: Eli Zaretskii
Subject: Re: stack overflow while using sml-mode.el
Date: Mon, 23 Oct 2000 17:12:07 +0200 (IST)

On 23 Oct 2000, Colin Walters wrote:

> > How do you know it's a stack overflow?
> 
> Well, because the stack had 2910 frames on it, with the first 1500
> being inside mark_object.  I assume the root cause of the bug isn't in
> the garbage collector, but I don't think that's a normal number of
> recursive calls.

Actually, having several thousands of recursive mark_object invocations 
is quite normal.  I was surprised at the time when I first saw this, so, 
at Richard Stallman's advice, I instrumented mark_object to print the 
recursion level, and saw even larger numbers.

If your runtime has a good documentation, you should be able to compare 
the value of the $esp register with the symbol which holds the stack 
limit.  Then you will know whether you have a stack overflow on your 
hands.  (Finding the symbol(s) which let you compute the stack limit is 
the part where you need the docs---or the sources.)

> >  (gdb) p ptr
> >  $6 = (struct Lisp_String *) 0x8366eb4
> >  (gdb) p *(struct Lisp_String *) 0x8366eb4
> 
> As per Stefan's advice, I did:
> 
> (gdb) p *ptr
> $13 = {
>   size = 18, 
>   size_byte = 404740268, 
>   intervals = 0x181fd8ac, 
>   data = "|"
> }

String data is invalid inside GC if this string was already marked :-(.
You should be able to see from the code whether the string pointed to 
by ptr is already marked or not.  If it is, you cannot look at that 
string's data.

FWIW, from the data you posted, I cannot even figure out why did it 
segfault.  Does ptr hold an invalid address or something?  If the pointer 
is invalid, how come GDB manages to dereference it?  If it is valid, why 
the crash?

I think this should be the first thing to figure out.

> > Can you find out what exactly was Emacs doing when it crashed (apart
> > of GC)?  Was it, per chance, matching a complicated regexp?
> 
> Ok, here's a summary of the stack:

Find the innermost invocation of Ffuncall and look at args[0].  It should 
be a symbol, a function name.  That will tell you which function is being 
invoked.  The rest of args[] are the arguments passed to that function.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]