Title xemacs 21.5 b28 segfaults upon exit on aix 5.2
Type defect Module core code 21.5
Severity inconvenience Platform other cpu, unix
Keywords Nosy List
These controls should only be changed by committers and tracker administrators.
Status chatting   Reason
Superseder   Submitted 2008-01-09.22:14:29
Priority normal   Assigned To

Created on 2008-01-19.04:58:06 by stephen, last changed 2008-01-23.10:48:29 by stephen.

msg496 [hidden] ([hidden]) Date: 2008-01-23.10:48:29
Supersedes issue217.

Thomas is now running under GDB as suggested.
msg125 [hidden] ([hidden]) Date: 2008-01-19.04:58:06
  Message-ID: <>
Thomas Mittelstaedt writes:

 > (gdb) bt
 > #0  0x1000460c in fatal_error_signal (sig=11) at emacs.c:3800
 > #1  0x000041ac in ?? ()
 > #2  0x00000000 in ?? ()

Can you just run XEmacs under gdb all the time?  (For me this doesn't
seem to cost anything but about 1MB of virtual memory.)  It is often
the case that the debugger is somehow able to save the backtrace,
although it can't get a good one from the core file.  The one above
says that fatal_error_signal was called literally from nowhere, which
isn't very helpful.

 > Fatal error: assertion failed, file window.c, line 2466, RECORD_TYPEP 
 > (obj, lrecord_type_window)

This says that some Lisp object was of unexpected type, but it doesn't
help us figure out how it got there.  All I can advise is caution.

The Lisp backtrace says Dired was doing something, but that's not very
helpful either (Lisp errors cannot crash XEmacs, it has to be a
problem in the C code).

XEmacs-Beta mailing list
Date User Action Args
2008-01-23 10:48:29stephensetstatus: new -> chatting
severity: inconvenience
messages: + msg496
module: + core code 21.5
priority: normal
platform: + other cpu, unix
type: defect
2008-01-23 10:47:25stephenlinkissue217 superseder
2008-01-19 04:58:06stephencreate