Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "Karl" == Karl M Hegbloom
<karlheg(a)bittersweet.inetarena.com> writes:
Karl> For the bug report I just sent, I included a stack dump generated by
Karl> running gdb on the core file, then typing the "where full" command.
Karl> There are strings in there that I believe are Lisp byte-code. Am I
Karl> correct? How do I go about finding out which Lisp program that is?
In general, it's difficult. and not generally useful.
I've occassionally found this very useful. Use pobj to print the
elements of the args arrays in the Ffuncall stack frames. args[0]
should be the function names.
If you run under the debugger, `lbt' is the debugger command
that
gives you a lisp stacktrace. See src/.gdbinit.
I've never found any use for that so far as it requires a running
xemacs process, i.e. doesn't work on core dumps or completely fubared
processes. :-)
Karl> Perhaps knowing that would help lead to finding out what
triggers a
Karl> segv during gc_sweep()?
It's more likely that bad gcpro happen in the C functions that get
called.
Karl, if you are trying to reproduce this, it might be useful to set
always_gc to 1 and perform whatever actions triggered the bug. Be
warned this is going to be very slow.
Gunnar