Thanks for answering given your situation! Hope your life stays
relatively unaffected and things improve!
"Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> writes:
Andreas, please make sure to at least CC the list. I live in a
although my daily life is relatively unaffected (in fact, I have more than usual
time for my hobbies, but have lost access to a lot resources I use for them)
and cannot promise quick response. CC'ing xemacs-beta and not trimming.
Sorry for forgetting to send a CC to the list. (Actually I was wondering
why my mail didn't show up on the list ...) Should one never trimm on
On Mon, Mar 14, 2011 at 11:47 PM, Andreas Goesele
> "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> writes:
>> What we need to diagnose a crash, usually, is a C backtrace. If you know
>> how to force XEmacs to crash, you can usually get the backtrace by starting
>> XEmacs in a debugger. On systems with gdb, something like
>> $ gdb /usr/local/bin/xemacs
>> (gdb) run
>> <some message about XEmacs crashing>
>> (gdb) bt
>> <long text of backtrace>
>> Then save the terminal output to a file, and attach it to your report.
>> The backtrace will usually run off the screen. If that makes it difficult
>> to capture all the output, you can run gdb as
>> $ gdb /usr/local/bin/xemacs 2>&1 | tee crash.log
> Strangely, on the day I reported the problem, I had a sure recipe to
> crash xemacs, but that doesn't work anymore. But once more writing an
> email resulted in a crash. This time not expanding an address, but just
> writing the first word. It seems it was linked to the following set of
> Parsing /home/user/.mailrc... done
> Parsing /home/user/.mailrc...
> Rebuilding aliases due to new aliases.
Which MUA are you using?
> Here there is the backtrace of the segfault. Given that there are
> debugging symbols, I don't know, whether that helps.
No, it doesn't help much. However, I can tell from the backtrace that
you crashed in Ffuncall (aka the lisp function funcall) which is very strange.
Since you're using a no-mule build of 21.4, I suspect it is related to
non-ASCII characters, but can't be sure.
I don't know offhand if there's any way to get the numeric addresses
of the arguments to the last Ffuncall. If there is, you should be able
to get at least some Lisp information.
First, see if you have a copy of .gdbinit. If not you can get one from
Then load it into gdb with "source .gdbinit". Then you can use "lbt"
a Lisp backtrace (which probably isn't very informative), "lbp <lisp
print the value of a Lisp expression, and "pobj" to convert C addresses to
Lisp object information.
I will do so with the next crash.
> GNU gdb (GDB) 7.0.1-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu".
> For bug reporting instructions, please see:
> Reading symbols from /usr/bin/xemacs21-nomule...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/xemacs21-nomule
> [Thread debugging using libthread_db enabled]
> Program received signal SIGSEGV, Segmentation fault.
> 0x080b6468 in Ffuncall ()
> (gdb) bt
> #0 0x080b6468 in Ffuncall ()
> #1 0x08096997 in ?? ()
> #2 0x08096e42 in funcall_compiled_function ()
> #3 0x080b6643 in Ffuncall ()
> #4 0x080b73e9 in run_hook_with_args_in_buffer ()
> #5 0x080b7598 in run_hook_with_args ()
> #6 0x080b76e6 in Frun_hooks ()
> #7 0x080b7719 in run_hook ()
> #8 0x08088b62 in Fexpand_abbrev ()
> #9 0x0809ceab in ?? ()
> #10 0x0809d0c1 in Fself_insert_command ()
> #11 0x080b67a6 in Ffuncall ()
> #12 0x08097960 in Fcall_interactively ()
> #13 0x080b8e5d in Fcommand_execute ()
> #14 0x080e3f0a in ?? ()
> #15 0x080e5a10 in Fdispatch_event ()
> #16 0x0809c2dc in Fcommand_loop_1 ()
> #17 0x080b9aaa in condition_case_1 ()
> #18 0x0809c54a in ?? ()
> #19 0x080b4551 in internal_catch ()
> #20 0x0809c840 in initial_command_loop ()
> #21 0x080b19ff in xemacs_21_4_22_i486_pc_linux ()
> #22 0x080b24dc in main ()
> Omnis enim res, quae dando non deficit, dum habetur et non datur,
> nondum habetur, quomodo habenda est.
> Augustinus, De doctrina christiana
Omnis enim res, quae dando non deficit, dum habetur et non datur,
nondum habetur, quomodo habenda est.
Augustinus, De doctrina christiana
XEmacs-Beta mailing list