9:13 p.m.
Does anybody have any particular good tips for how to debug crashes
that happen in GC ?
I've contrived to provoke (repeatably) a crash in my own version,
which, upon bisection, turns out also to happen in the vanilla 21.4.21
code, albeit compiled with error-checking and debug, and without any
optimization.
(Load a 45MB VM folder, wait a while, and some time later VM does
something and then GC happens and crashes.)
It's a bit intimidating at first sight, since it happens about 300000
stack frames down, which makes the back-trace a little hard to read...
Since it's not my changes that are causing it, I'm not in a huge
hurry, but nonetheless, I don't want XEmacs segfaulting on me ever!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:42 p.m.
Aargh. Naturally, a couple of minutes after posting, I realize I'm
being an idiot. Sorry to use you all as a collective pair programmer...
I've contrived to provoke (repeatably) a crash in my own version,
...
It's a bit intimidating at first sight, since it happens about
300000
stack frames down, which makes the back-trace a little hard to read...
Exceeding the stack limit is signalled by a segfault, of course.
What a waste of time...
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:02 a.m.
Julian Bradfield writes:
(Load a 45MB VM folder,
I regularly do that. So it's not just size, but size (I would guess)
plus something folder-specific.
wait a while, and some time later VM does something and then GC
happens and crashes.)
As you point out later, that's presumably a problem with stack depth
being exceeded. However, we'd like to know why VM or GC is using so
much stack. If you don't get a Lisp backtrace, or you don't trust the
one you're seeing, try
$ gdb xemacs
(gdb) run
# provoke crash
(gdb) source xemacs-sources/src/.gdbinit # if you aren't in src/
(gdb) lbt
That should tell us what VM was up to at the time. It's possible that
GC has its shorts in a (Moebius) knot; do the last few of those stack
frames seem to be going in circles?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:35 a.m.
As you point out later, that's presumably a problem with stack
depth
being exceeded. However, we'd like to know why VM or GC is using so
much stack.
As I said, I compiled without any optimization (because optimized code
is too hard to debug for the kind of simple basic error one makes when
doing first-cut code!). So in particular there's no tail recursion
optimization, which GC relies upon to avoid stack blow-up in normal
life. In a VM folder with 30k messages, it doesn't surprise me that
the Lisp object graph might contain paths 300k long. (I guess that GC
explores depth-first rather than breadth-first?)
If I remove the default limit (8MB on my laptop) on stack size, the
problem goes away, so there's no infinite recursion going on.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:13 a.m.
Julian Bradfield writes:
>As you point out later, that's presumably a problem with
stack depth
>being exceeded. However, we'd like to know why VM or GC is using so
>much stack.
As I said, I compiled without any optimization (because optimized code
is too hard to debug for the kind of simple basic error one makes when
doing first-cut code!). So in particular there's no tail recursion
optimization, which GC relies upon to avoid stack blow-up in normal
life.
Ah, OK, I didn't know that. Thanks for the explanation. So I guess
we're cool with this ... maybe we should put something in the FAQ.
For GCC at least there's probably an option to specify that
optimization.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:16 a.m.
Stephen writes:
> As I said, I compiled without any optimization (because
optimized code
> is too hard to debug for the kind of simple basic error one makes when
> doing first-cut code!). So in particular there's no tail recursion
> optimization, which GC relies upon to avoid stack blow-up in normal
> life.
Ah, OK, I didn't know that. Thanks for the explanation. So I guess
we're cool with this ... maybe we should put something in the FAQ.
For GCC at least there's probably an option to specify that
optimization.
Yes. Helpfully called -foptimize-sibling-calls .
Worth noting that this kicks in at -O2, so an -O1 optimized program
will still blow up the stack.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5848
days inactive
5849
days old
5 comments
2 participants
participants (2)
-
Julian Bradfield -
Stephen J. Turnbull