i'm almost positive this is due to an oversight on my part when modifying the
gcpro-popup-callback mechanism for use with kkcc. patch forthcoming as soon as
i test it.
ben
----- Original Message -----
From: "Kaarthik Sivakumar" <kaarthik(a)comcast.net>
To: "Stephen J. Turnbull" <stephen(a)xemacs.org>
Cc: "Pete Siemsen" <siemsen(a)ucar.edu>; "XEmacs Beta"
<xemacs-beta(a)xemacs.org>;
<ben(a)xemacs.org>; <andy(a)xemacs.org>
Sent: Wednesday, March 05, 2003 9:36 PM
Subject: Re: [Bug: 21.5-b11] assertion failed
>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>>> "Pete" == Pete Siemsen <siemsen(a)ucar.edu>
writes:
SJT> Thanks for the report. I don't know what is causing these, but I
SJT> just saw one, too.
I sent in a bug report about this one sometime last week. I can still
see these crashes.
SJT> I don't think Perl has anything to do with it, it's native widgets, I
SJT> think (I see them sporadically in customize buffers and a local
SJT> library I have that uses native widgets via widget.el, always when
SJT> clicking on something).
SJT> [4 uninteresting frames elided]
Pete> #5 0x9c5a4 in zero_out_command_line_status_vars () at emacs.c:4283
SJT> You only got 5 frames of backtrace? Urk.
Does this help?
Program received signal SIGABRT, Aborted.
0x28624b64 in kill () from /usr/lib/libc.so.4
(gdb) bt
#0 0x28624b64 in kill () from /usr/lib/libc.so.4
#1 0x2866610a in abort () from /usr/lib/libc.so.4
#2 0x80c5eaf in really_abort () at emacs.c:4394
#3 0x80c5c07 in assert_failed (file=0x82e948c "gui-x.c", line=284,
expr=0x82e82c0 "RECORD_TYPEP (obj, lrecord_type_cons)") at emacs.c:3728
#4 0x82271ff in popup_selection_callback (widget=0x8d86200, ignored_id=65544,
client_data=0x8d508dc) at lisp.h:1700
#5 0x8249b75 in xlw_tab_control_callback (w=0x8d86200, client_data=0x8a95b60,
call_data=0x8d86200) at lwlib-Xlw.c:363
#6 0x28432db9 in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6
#7 0x824de0d in XawTabsSetTop (w=0x8d86200, callCallbacks=1) at
xlwtabs.c:1310
#8 0x824ee9c in TabsSelect (w=0x8cdde00, event=0xbfbff440,
params=0x0,
num_params=0x2846f0b4) at xlwtabs.c:1079
#9 0x2845fa82 in HandleActions () from /usr/X11R6/lib/libXt.so.6
#10 0x2845ff03 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.6
#11 0x28460441 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6
#12 0x2843dd6d in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#13 0x2843e701 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#14 0x2843e94e in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#15 0x284494c5 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#16 0x820c80e in emacs_Xt_next_event (emacs_event=0x84cf48c) at
event-Xt.c:2845
#17 0x80dc377 in event_stream_next_event (event=0x84cf48c)
at event-stream.c:2078
#18 0x80dc6bb in next_event_internal (target_event=139261068, allow_queued=1)
at event-stream.c:2142
#19 0x80dcd9a in Fnext_event (event=139261068, prompt=678174468)
at event-stream.c:2367
#20 0x80a2afc in Fcommand_loop_1 () at cmdloop.c:568
#21 0x80a2dca in command_loop_1 (dummy=678174468) at cmdloop.c:488
#22 0x80c83c7 in condition_case_1 (handlers=678172356,
bfun=0x80a2d8c <command_loop_1>, barg=678174468,
hfun=0x80a2e3c <cmd_error>, harg=678174468) at eval.c:1917
#23 0x80a2f33 in command_loop_2 (dummy=678174468) at cmdloop.c:251
#24 0x80d109c in internal_catch (tag=677963412,
func=0x80a2ef0 <command_loop_2>, arg=678174468, threw=0x0, thrown_tag=0x0)
at eval.c:1527
#25 0x80a27ac in initial_command_loop (load_me=678174468) at cmdloop.c:300
#26 0x80c3e83 in xemacs_21_5_b11_i386_unknown_freebsd4_7 (argc=1,
argv=0xbfbff98c, envp=0xbfbff994, restart=0) at emacs.c:2400
#27 0x80c5fa0 in main (argc=1, argv=0xbfbff98c, envp=0xbfbff994)
at emacs.c:2830
SJT> If you go up a few frames (gdb command is "up" oddly enough ;-), and
SJT> do
SJT> (gdb) print * (struct lrecord_header *) client_data
SJT> $5 = {type = 63, mark = 0, c_readonly = 1, lisp_readonly = 1, unused =
1824183}
SJT> (gdb) print (enum lrecord_type) lrecord_type_free + 0
SJT> $11 = 63
SJT> Suspicious, huh?
SJT> I'd be interested to know what the type member is in your crash. The
SJT> fact that I got "free" suggests uninitialized data somewhere, but if
SJT> your stack was smashed (as the small number of frames suggests), then
SJT> that could just be a random number. If you get a different number,
SJT> you can just report it, but if you're curious the list of types is in
SJT> enum lrecord_type in src/lrecord.h.
I assume in the crash above it would be in frame 5. I get the
following:
(gdb) fr 5
#5 0x8249b75 in xlw_tab_control_callback (w=0x8d86200, client_data=0x8a95b60,
call_data=0x8d86200) at lwlib-Xlw.c:363
363 instance->info->selection_cb (w, id, widget_arg);
(gdb) p *(struct lrecord_header*)client_data
$1 = {type = 0, mark = 0, c_readonly = 1, lisp_readonly = 1, unused = 72123}
Actually I am quite interested in debugging this crash and I have been
trying to read the Internals info doc. Its been a little slow though,
there is so much to learn. Someday soon...
Kaarthik