Issue68

classification
Title [Bug: 21.5-b28] Crash after server password prompt(ERC)
Type defect Module core code 21.5
Severity crash Platform x86, unix, xt
Keywords Nosy List
explanation
process
These controls should only be changed by committers and tracker administrators.
Status chatting   Reason
Superseder   Submitted 2007-11-05.07:03:36
Priority normal   Assigned To

Created on 2008-01-19.04:58:03 by stephen, last changed 2008-01-22.00:08:34 by stephen.

Files
File name Uploaded Type Edit Remove
gdb.xemacs.txt.gz FKtPp, 2008-01-19.06:43:02 application/octet-stream
unnamed FKtPp, 2008-01-19.06:43:02 text/plain
Messages
msg445 [hidden] ([hidden]) Date: 2008-01-22.00:08:34
Supersedes issue154.
msg223 [hidden] ([hidden]) Date: 2008-01-19.06:43:02
  Message-ID: <20071107074717.GB4595@debian>
On Wed, Nov 07, 2007 at 03:54:30PM +0900, Stephen J. Turnbull wrote:
> FKtPp writes:
> 
>  > > do you also have a lisp Backtrace show where in erc the crash happens?
>  > > 
>  > 
>  > Sorry, for now I don't know how to produce that from a XEmacs crash...
> 
> After sourcing .gdbinit and crashing, try lbt in gdb.
> 

Well, rewroked as you wish.

--8<---------------cut here---------------start------------->8---

Fatal error: assertion failed, file print.c, line 1522, ABORT()

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x2ad8295aa1e0 (LWP 4658)]
0x00002ad8285a36a5 in raise () from /lib/libc.so.6
(gdb) lpt
Undefined command: "lpt".  Try "help".
(gdb) lbt
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (print-message-label)
  display-error((invalid-function #<EMACS BUG: freed lrecord object 0x111dac0 Save your buffers immediately and please report this bug>) t)
  # bind (etype debug-on-error inhibit-quit error-object)
  command-error((invalid-function #<EMACS BUG: freed lrecord object 0x111dac0 Save your buffers immediately and please report this bug>))
  # (catch top-level ...)

(gdb) up 9
#9  0x0000000000470d81 in execute_optimized_program (
    program=0x151c910 "�\033�\032\r�\034�\021�\211\020\026\035�\026\036\016\037�\004� \210� \210\r\026 ��!\210��\f�a�\037�\rA@!�\025�\rA@GU�\r�\rA@�H!�\004Ъ\035Ѫ\032\f�a�\004Ҫ\022\f�s�\004Ԫ\n\f�a�\004֪\002�\"\210�\r�\"\210� �\v��\016!\"\210��!\210+�\207q", stack_depth=6, constants_data=0xb133d0)
    at bytecode.c:862
(gdb) pobj constants_data
Unknown Lisp Object type
$1 = (Lisp_Object *) 0xb133d0
(gdb) down 1
#8  0x00000000004b5d16 in Ffuncall (nargs=3, args=0x7fff847e0768)
    at eval.c:3928
(gdb) pobj args[0]
$2 = (struct Lisp_Symbol *) 0x9b1af0
$3 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 3897}, next = 0x0, name = 12653648, value = 9672544, 
  function = 10266152, plist = 10223248}
Symbol name: display-error
(gdb) ldp args[0]
Lisp => display-error
(gdb) pobj args[1]
$4 = (struct Lisp_Cons *) 0x11ecb00
$5 = {lheader = {type = 6, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 392708}, car_ = 10034704, cdr_ = 18794496}
(gdb) ldp args[1]
Lisp => (invalid-function #<EMACS BUG: freed lrecord object 0x111dac0 Save your buffers immediately and please report this bug>)
(gdb) pobj args[2]
$6 = (struct Lisp_Symbol *) 0x9bf8c0
$7 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 264}, next = 0x0, name = 12705424, value = 10221760, 
  function = 9672544, plist = 10223248}
Symbol name: t
(gdb) ldp args[2]
Lisp => t
(gdb) 
--8<---------------cut here---------------end--------------->8---
msg222 [hidden] ([hidden]) Date: 2008-01-19.06:43:02
  Message-ID: <20071106120632.GC13040@debian>
On Tue, Nov 06, 2007 at 03:58:55AM +0900, Stephen J. Turnbull wrote:
> FKtPp writes:
> 
>  > > If you have the core file, start gdb /path/to/xemacs, then source
>  > > .gdbinit,
>  > 
>  > It seemed that, I don't have `pobj' nor `ldp' command defined. Is that a gdb
>  > standard command or you defined for self needs?  How to define it? 
>  > What does it do?
> 
> "source .gdbinit" is the key.  It lives in the XEmacs sources src/
> subdirectory next to the xemacs binary.
> 
> pobj and ldp are two commands that take a C pointer to a Lisp_Object
> and print it out in various ways.  pobj shows the relationship of the
> C struct to the Lisp object more clearly, while ldp actually uses the
> Lisp engine's printer to show you what you would see if you typed M-:
> obj RET in XEmacs.  These user commands are defined in .gdbinit.
> 
> If you start gdb from the same directory where .gdbinit is, gdb will
> read it automatically.  (Thus "cd /path/to/xemacsstuff; gdb xemacs"
> has some advantages over "gdb /path/to/xemacsstuff/xemacs".)

Thanks for your time and patient, I've know how to do it now. And this is 
the result:

--8<---------------cut here---------------start------------->8---

Fatal error: assertion failed, file print.c, line 1522, ABORT()

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x2b8774f6a1e0 (LWP 13108)]
0x00002b8773f636a5 in raise () from /lib/libc.so.6
(gdb) up 9
#9  0x0000000000470d81 in execute_optimized_program (
    program=0x131ee60 "~\033~\032\r~\034~\021~\211\020\026\035~\026\036\016\037~\004~ \210~ \210\r\026 ~~!\210~~\f~a~\037~\rA@!~\025~\rA@GU~\r~\rA@~H!~\004~\035~\032\f~a~\004~\022\f~s~\004~\n\f~a~\004~\002~\"\210~\r~\"\210~ ~\v~~\016!\"\210~~!\210+~\207!", stack_depth=6, constants_data=0xb133d0)
    at bytecode.c:862
(gdb) pobj constants_data
Unknown Lisp Object type
$1 = (Lisp_Object *) 0xb133d0
(gdb) down 1
#8  0x00000000004b5d16 in Ffuncall (nargs=3, args=0x7fff38e20d18)
    at eval.c:3928
(gdb) pobj args[0]
$2 = (struct Lisp_Symbol *) 0x9b1af0
$3 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 3897}, next = 0x0, name = 12653648, value = 9672544, 
  function = 10266152, plist = 10223248}
Symbol name: display-error
(gdb) pobj args[1]
$4 = (struct Lisp_Cons *) 0x11baa78
$5 = {lheader = {type = 6, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 390533}, car_ = 10034704, cdr_ = 18593336}
(gdb) pobj args[2]
$6 = (struct Lisp_Symbol *) 0x9bf8c0
$7 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0, 
    uid = 264}, next = 0x0, name = 12705424, value = 10221760, 
  function = 9672544, plist = 10223248}
Symbol name: t
(gdb) ldp args[0]
Lisp => display-error
(gdb) ldp args[1]
(invalid-function #<EMACS BUG: freed lrecord object 0x111dd60 Save your buffers immediately and please report this bug>)
(gdb) ldp args[2]
Lisp => t
(gdb) 
--8<---------------cut here---------------start------------->8---

> 
>  > I've done that, so what next? I can tempraryly using gedit as my editor.
> 
> Just start another instance of XEmacs.  In fact, if you're into heavy
> debug and fix mode, it often makes sense to have a cycle like "make;
> cd src; ./xemacs" then in XEmacs use M-x gdb to start gdb-mode which
> gives you a somewhat useful toolbar and multiple windows on debugger
> data.  (Of course you have to be careful to avoid tickling the crash
> you're debuging in the parent xemacs!  Or you could use a stable
> version that doesn't crash.)
> 

Yes, I like this :p But I still have to use some other editor because
of the multi-gnuserv confusing.
msg221 [hidden] ([hidden]) Date: 2008-01-19.06:43:02
  Message-ID: <20071105091820.GC4390@debian>
Sorry, I forgot the attachment -_-
msg84 [hidden] ([hidden]) Date: 2008-01-19.04:58:03
  Message-ID: <87d4ul4956.fsf@uwakimon.sk.tsukuba.ac.jp>
FKtPp writes:
 > On Wed, Nov 07, 2007 at 03:54:30PM +0900, Stephen J. Turnbull wrote:
 > > FKtPp writes:
 > > 
 > >  > > do you also have a lisp Backtrace show where in erc the crash happens?
 > >  > > 
 > >  > 
 > >  > Sorry, for now I don't know how to produce that from a XEmacs crash...
 > > 
 > > After sourcing .gdbinit and crashing, try lbt in gdb.

Thanks!  Unfortunately, it looks like this is a problem with the
garbage collector.  (If you don't know what that means, basically, we
periodically trawl through the list of *all* Lisp objects for ones
that there are no active pointers to, and return them to the list of
free memory blocks.  Only after that happens---typically long after
the bug bites---can a "freed Lisp_Object" error surface.)  Hard to
diagnose.

It may take a while to work through this. :-(

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg83 [hidden] ([hidden]) Date: 2008-01-19.04:58:03
  Message-ID: <87r6j2ilzt.fsf@uwakimon.sk.tsukuba.ac.jp>
FKtPp writes:

 > > do you also have a lisp Backtrace show where in erc the crash happens?
 > > 
 > 
 > Sorry, for now I don't know how to produce that from a XEmacs crash...

After sourcing .gdbinit and crashing, try lbt in gdb.

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg82 [hidden] ([hidden]) Date: 2008-01-19.04:58:03
  Message-ID: <87y7dcsemo.fsf@uwakimon.sk.tsukuba.ac.jp>
FKtPp writes:

 > > If you have the core file, start gdb /path/to/xemacs, then source
 > > .gdbinit,
 > 
 > It seemed that, I don't have `pobj' nor `ldp' command defined. Is that a gdb
 > standard command or you defined for self needs?  How to define it? 
 > What does it do?

"source .gdbinit" is the key.  It lives in the XEmacs sources src/
subdirectory next to the xemacs binary.

pobj and ldp are two commands that take a C pointer to a Lisp_Object
and print it out in various ways.  pobj shows the relationship of the
C struct to the Lisp object more clearly, while ldp actually uses the
Lisp engine's printer to show you what you would see if you typed M-:
obj RET in XEmacs.  These user commands are defined in .gdbinit.

If you start gdb from the same directory where .gdbinit is, gdb will
read it automatically.  (Thus "cd /path/to/xemacsstuff; gdb xemacs"
has some advantages over "gdb /path/to/xemacsstuff/xemacs".)

 > I've done that, so what next? I can tempraryly using gedit as my editor.

Just start another instance of XEmacs.  In fact, if you're into heavy
debug and fix mode, it often makes sense to have a cycle like "make;
cd src; ./xemacs" then in XEmacs use M-x gdb to start gdb-mode which
gives you a somewhat useful toolbar and multiple windows on debugger
data.  (Of course you have to be careful to avoid tickling the crash
you're debuging in the parent xemacs!  Or you could use a stable
version that doesn't crash.)

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
msg81 [hidden] ([hidden]) Date: 2008-01-19.04:58:03
  Message-ID: <87myttjhrr.fsf@uwakimon.sk.tsukuba.ac.jp>
It's me FKtPp ;) writes:

 > #8  0x00000000004b5d16 in Ffuncall (nargs=3, args=0x7ffffe0ddba8)
 >     at eval.c:3928
 > #9  0x0000000000470d81 in execute_optimized_program (
 >     program=0x15dacf0 "~\033~\032\r~\034~\021~\211\020\026\035~\026\036\016\037~\004~ \210~ \210\r\026 ~~!\210~~\f~a~\037~\rA@!~\025~\rA@GU~\r~\rA@~H!~\004~\035~\032\f~a~\004~\022\f~s~\004~\n\f~a~\004\002~\"\210~\r~\"\210~ ~\v~~\016!\"\210~~!\210+~\207~\a", stack_depth=6, constants_data=0xb107e0)
 >     at bytecode.c:862

Your backtrace seems to be corrupt (the '~' characters).  If you
happen to have a clear copy that would be nice (but don't kill
yourself to get it, it looks like the funcall in frame #8 is more
directly related).

If you have the core file, start gdb /path/to/xemacs, then source
.gdbinit, and do "up 9" then "pobj constants_data".  (I think that's
the right place to do it, you may need to be at frame #8.)  Also in
frame #8 I'd love to have a look at args[0], args[1], and args[2]
under pobj.

It might also be useful to use ldp on those, but that needs to be done
on a running xemacs, the core file isn't good enough.

Since you seem to be eliciting a lot of crashes, may I recommend that
you run xemacs under gdb all the time?  This doesn't cost much except
a few dozen KB of RAM, and some weirdness with C-z (which tends to
throw you into the debugger rather than whatever you had bound to that
key).

Also, your crashes seem to be kinda intermittent (eg, this one looks
like a garbage collection crash) which means that we've probably got a
bug pretty far away from where the crash actually happened.  If you
could hang on to your crashed process until we've had a chance to ask
it a few questions, that can often be of enormous help in tracking
these down.  Don't forget to mention it, keeping crashed processes
does use up system resources, including your freedom to restart the
system.  We wouldn't want to keep you waiting!

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta@xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
History
Date User Action Args
2008-01-22 00:08:34stephensetseverity: crash
messages: + msg445
module: + core code 21.5
priority: normal
platform: + x86, unix, xt
type: defect
2008-01-22 00:07:18stephenlinkissue154 superseder
2008-01-19 06:43:02FKtPpsetmessages: + msg223
2008-01-19 06:43:02FKtPpsetmessages: + msg222
2008-01-19 06:43:02FKtPpsetfiles: + gdb.xemacs.txt.gz, unnamed
messages: + msg221
2008-01-19 04:58:03stephensetmessages: + msg84
2008-01-19 04:58:03stephensetmessages: + msg83
2008-01-19 04:58:03stephensetstatus: new -> chatting
messages: + msg82
2008-01-19 04:58:03stephencreate