9:34 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> I don't understand why XtWidgetToApplicationContext is calling
Stephen> `malloc_after', which is a static XEmacs function. Could you try
Stephen> rebuilding with --with-cflags="--no-thread-jumps
--no-crossjumping"
Stephen> and seeing if the backtrace gives more detail at that point?
Here you go. Hmm. This might not be want you wanted. This is from
my hg repo from a week or two ago, and not from the 2008-06-01 tree.
And I see the backtrace is different if I get rid of the splash screen
and then close the window.
I can provide more info for whichever build you think will be most
useful to track this down. I don't know anything about X so this is
hard for me to look into myself.
Ray
#0 0xfed3639c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#1 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#2 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#3 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#4 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#5 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#6 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#7 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#8 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#9 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#10 0xfed35fcc in XtGetValues () from /usr/openwin/lib/libXt.so.4
#11 0x003032e0 in x_set_frame_text_value (f=0xea1600,
value=0xeab760 "XEmacs: *scratch*", Xt_resource_name=0x3deb64
"title",
Xt_resource_encoding_name=0x3dea76 "titleEncoding")
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame-x.c:667
#12 0x003033a8 in x_set_title_from_ibyte (f=0xea1600,
name=0xeab760 "XEmacs: *scratch*")
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame-x.c:680
#13 0x00163a60 in update_frame_title (f=0xea1600)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:3524
#14 0x002587bc in redisplay_frame (f=0xea1600, preemption_check=1)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/redisplay.c:6960
#15 0x00258df0 in redisplay_device (d=0xd69f00, automatic=1)
- at /apps/public/XEmacs/src/hg/xemacs-beta/src/redisplay.c:7034
#16 0x00259970 in redisplay_without_hooks ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/redisplay.c:7109
#17 0x00259d70 in redisplay_no_pre_idle_hook ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/redisplay.c:7180
#18 0x000ecf98 in Fnext_event (event=6981212, prompt=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/event-stream.c:2265
#19 0x000883b4 in Fcommand_loop_1 ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:599
#20 0x00088018 in command_loop_1 (unused_dummy=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:505
#21 0x000c9d30 in condition_case_1 (handlers=4290660,
bfun=0x87fd4 <command_loop_1>, barg=4290564, hfun=0x87988 <cmd_error>,
harg=4290564) at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:1946
#22 0x00087b5c in command_loop_3 ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:262
#23 0x00087b8c in command_loop_2 (unused_dummy=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:275
#24 0x000c9528 in internal_catch (tag=4371348, func=0x87b7c <command_loop_2>,
arg=4290564, threw=0x0, thrown_tag=0x0, backtrace_before_throw=0x0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:1552
#25 0x00087d30 in initial_command_loop (load_me=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:313
#26 0x000c21d0 in xemacs_21_5_b28_sparc_sun_solaris2_10 (argc=2,
argv=0xffbfef2c, unused_envp=0x0, restart=0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:2718
#27 0x000c308c in main (argc=2, argv=0xffbfef2c, unused_envp=0xffbfef38)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:3225
(
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:39 p.m.
New subject: [Bug: 21.5-b28] Crash when closing xemacs via window manager
Due to lack of time, bright ideas, and access to X documentation, I'm
going to have to postpone most work on this until I get back to Japan
(nominally August 21, but what with the quarter starting on September
1, more likely early September). Anybody with suggestions, please
pipe up! I can probably review patches, if anybody gets that far.
Raymond Toy writes:
Here you go. Hmm. This might not be want you wanted. This is from
my hg repo from a week or two ago, and not from the 2008-06-01 tree.
And I see the backtrace is different if I get rid of the splash screen
and then close the window.
This backtrace comes from a crash, right? But it doesn't look like
one, usually frame #0 in a crash backtrace is an abort or signal
handler in libc.
If it is a crash, it's crashing in a completely different place, wich
could mean (a) two crashes or (b) one or both of the optimizations was
seriously misleading us about where the crash was actually happening.
I can provide more info for whichever build you think will be most
useful to track this down. I don't know anything about X so this is
hard for me to look into myself.
This looks like Xt is recursively calling itself somehow. I don't
understand why that should happen, either.
The only thing I can think of, again, is that the window manager has
deleted a window out from under us, and we don't find out until we've
spewed a ton of X protocol out to the server. But I would think Xlib
would handle that for us, in cooperation with the Xserver.
#0 0xfed3639c in CallGetValuesHook () from
/usr/openwin/lib/libXt.so.4
#1 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#2 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#3 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#4 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#5 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#6 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#7 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#8 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#9 0xfed3634c in CallGetValuesHook () from /usr/openwin/lib/libXt.so.4
#10 0xfed35fcc in XtGetValues () from /usr/openwin/lib/libXt.so.4
#11 0x003032e0 in x_set_frame_text_value (f=0xea1600,
value=0xeab760 "XEmacs: *scratch*", Xt_resource_name=0x3deb64
"title",
Xt_resource_encoding_name=0x3dea76 "titleEncoding")
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame-x.c:667
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:18 p.m.
New subject: [Bug: 21.5-b28] Crash when closing xemacs via window manager
Stephen J. Turnbull wrote:
Due to lack of time, bright ideas, and access to X documentation,
I'm
going to have to postpone most work on this until I get back to Japan
(nominally August 21, but what with the quarter starting on September
1, more likely early September). Anybody with suggestions, please
pipe up! I can probably review patches, if anybody gets that far.
I'm in no hurry, since I rarely close xemacs with the window manager. I
appreciate your help very much.
Raymond Toy writes:
> Here you go. Hmm. This might not be want you wanted. This is from
> my hg repo from a week or two ago, and not from the 2008-06-01 tree.
> And I see the backtrace is different if I get rid of the splash screen
> and then close the window.
This backtrace comes from a crash, right? But it doesn't look like
one, usually frame #0 in a crash backtrace is an abort or signal
handler in libc.
Yes, it is from a crash. I was running it in gdb and that's the
backtrace that was produced. I ran it again just now, and I see the
backtrace is slightly different. There are fewer calls to
CallGetValuesHook. But I also moved the window to a different place
before closing it.
Without knowing anything about X, the backtrace looks as if xemacs is
trying to redisplay the frame and update the frame title, after the
window has been closed.
The back trace is also different if I click on the splash screen to get
rid of it and then close the window. This, perhaps, looks a bit better.
The backtrace is appended below.
Ray
Fatal error: assertion failed, file
/apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c, line 3115,
RECORD_TYPEP (obj, ty)
Program received signal SIGABRT, Aborted.
0xfe7469ec in _lwp_kill () from /lib/libc.so.1
(gdb) bt
#0 0xfe7469ec in _lwp_kill () from /lib/libc.so.1
#1 0xfe6e4a0c in raise () from /lib/libc.so.1
#2 0xfe6c10e0 in abort () from /lib/libc.so.1
#3 0x000c5bc4 in really_abort ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:4745
#4 0x000c40bc in assert_failed (
file=0x393ea8 "/apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c",
line=3115, expr=0x38b3f0 "RECORD_TYPEP (obj, ty)")
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:4039
#5 0x000f7820 in wrap_record_1 (ptr=0x22880dd5, ty=lrecord_type_frame,
file=0x393ea8 "/apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c",
line=3115) at lrecord.h:1505
#6 0x0015f068 in frame_conversion_internal (f=0x22880dd5,
pixel_to_char=CHAR_TO_TOTAL_PIXEL, pixel_width=0xffbfcb30,
pixel_height=0xffbfcb2c, char_width=0xffbfcb00, char_height=0xffbfcb04,
real_face=0) at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:3115
#7 0x0015fba8 in char_to_pixel_size (f=0x22880dd5, char_width=80,
char_height=40, pixel_width=0xffbfcb30, pixel_height=0xffbfcb2c)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:3204
#8 0x00358d18 in EmacsFrameSetCharSize (widget=0xe90800, columns=80,
rows=40)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/EmacsFrame.c:649
#9 0x00307fd0 in x_set_frame_size (f=0xea1600, cols=80, rows=40)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame-x.c:2317
---Type <return> to continue, or q <return> to quit---
#10 0x0015e238 in internal_set_frame_size (f=0xea1600, cols=80, rows=40,
pretend=0) at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:2816
#11 0x0015ed6c in Fset_frame_pixel_size (frame=15341056, width=1327,
height=1321, pretend=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:3045
#12 0x000d02c4 in Ffuncall (nargs=4, args=0xffbfce3c)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3928
#13 0x00072698 in execute_optimized_program (
program=0xf912d0
"�\t�H\bs�\006��\t\"\210\t�H\t�H\bs�\006��\t\"\210\t�H\t�H\bs�\006��\t\"\210\t�H#\207\026\b��",
stack_depth=6, constants_data=0x64fad0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:862
#14 0x000cfaf0 in funcall_compiled_function (fun=6612180, nargs=1,
args=0xffbfd158) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#15 0x000d0750 in Ffuncall (nargs=2, args=0xffbfd154)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3967
#16 0x00072698 in execute_optimized_program (
program=0xe90810
"�\211\026&\026'�\026)�\f!\210�\r!\210\016*�＠\r�H\vs�\006��\r\"\210\r�H\r�H\vs�\006��\r\"\210\r�H\032\211\036\020�\f�\"k�\b�\f�\016\020#\210\n�\f�\"k�\a�\f�\n#\210*�\f!\036(�\r�H\vs�\006��\r\"\210\r�H��\f!!Z��\f!#\210��\f!!\210�\211C\031\030�\r\016(\r�H\vs�\006��\r\"\210\r�H�\t%\210\b�\005�\b!\210\r�H\vs�\006��\r\"\210\r�H\026&\r�H\vs�\006��\r\"\210\r�H\026'\r�H\vs�\006�"...,
stack_depth=7, constants_data=0x658010)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:862
---Type <return> to continue, or q <return> to quit---
#17 0x000cfaf0 in funcall_compiled_function (fun=6612136, nargs=2,
args=0xffbfd470) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#18 0x000d0750 in Ffuncall (nargs=3, args=0xffbfd46c)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3967
#19 0x00072698 in execute_optimized_program (
program=0xf91350 "\n�H\bs�\006��\n\"\210\n�H\031�\t!�\r�\n�
\"?�\005�\t\n\")\207", stack_depth=3, constants_data=0x64fb10)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:862
#20 0x000cfaf0 in funcall_compiled_function (fun=6612092, nargs=1,
args=0xffbfd778) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#21 0x000d0750 in Ffuncall (nargs=2, args=0xffbfd774)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3967
#22 0x00072698 in execute_optimized_program (program=0xf600f0
"�\b!\210�\207",
stack_depth=2, constants_data=0x5f0670)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:862
#23 0x000cfaf0 in funcall_compiled_function (fun=6612048, nargs=1,
args=0xffbfd998) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#24 0x000ceec0 in Feval (form=7437420)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3737
#25 0x000c75c0 in Fprogn (args=7437444)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:954
#26 0x000d738c in unbind_to_hairy (count=5)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:6167
---Type <return> to continue, or q <return> to quit---
#27 0x0007286c in execute_optimized_program (
program=0xf3d6d0 "\212\n�\v� � a�\004\t�\b�\f\v�#�\021�
\030�\216�\f\v�#*�\004��!)\207", stack_depth=4, constants_data=0x713c90)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:873
#28 0x000cfaf0 in funcall_compiled_function (fun=7394868, nargs=2,
args=0xffbfdf38) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#29 0x000d0750 in Ffuncall (nargs=3, args=0xffbfdf34)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3967
#30 0x00072698 in execute_optimized_program (
program=0xf4f710 "�\t�\"\210���� \"s�\006��!�S��!�?� �\034\211\035�
�\r＠!�s�\022�\r＠!\033�\r＠\v\"\210\v)�\003�\024\rA\211\025��\f?�\021\212�
\030�\216� \210� \210��!+*�\020��!�\v\n�\006\n�!�\003� \207", stack_depth=5,
constants_data=0x713510)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/bytecode.c:862
#31 0x000cfaf0 in funcall_compiled_function (fun=7459920, nargs=0,
args=0xffbfe2b0) at
/apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3514
#32 0x000d0750 in Ffuncall (nargs=1, args=0xffbfe2ac)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3967
#33 0x000d26c4 in call0 (fn=4393708)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:4565
#34 0x0008c348 in delete_console_internal (con=0x9a2400, force=1,
called_from_kill_emacs=0, from_io_error=0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/console.c:739
---Type <return> to continue, or q <return> to quit---
#35 0x000a33f4 in delete_device_internal (d=0xd69f00, force=1,
called_from_delete_console=0, from_io_error=0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/device.c:825
#36 0x00159bdc in delete_frame_internal (f=0xea1600, force=1,
called_from_delete_device=0, from_io_error=0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:1476
#37 0x0015af44 in Fdelete_frame (frame=15341056, force=4290588)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/frame.c:1855
#38 0x000ce6c0 in Feval (form=8875224)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3676
#39 0x000d01f8 in Ffuncall (nargs=2, args=0xffbfe798)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:3928
#40 0x000d2754 in call1 (fn=4394860, arg0=8875224)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:4580
#41 0x000f272c in execute_command_event (command_builder=0xd5f480,
event=6981328)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/event-stream.c:4283
#42 0x000f39c4 in Fdispatch_event (event=6981328)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/event-stream.c:4640
#43 0x000883c0 in Fcommand_loop_1 ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:600
#44 0x00088018 in command_loop_1 (unused_dummy=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:505
---Type <return> to continue, or q <return> to quit---
#45 0x000c9d30 in condition_case_1 (handlers=4290660,
bfun=0x87fd4 <command_loop_1>, barg=4290564, hfun=0x87988 <cmd_error>,
harg=4290564) at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:1946
#46 0x00087b5c in command_loop_3 ()
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:262
#47 0x00087b8c in command_loop_2 (unused_dummy=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:275
#48 0x000c9528 in internal_catch (tag=4371348, func=0x87b7c
<command_loop_2>,
arg=4290564, threw=0x0, thrown_tag=0x0, backtrace_before_throw=0x0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/eval.c:1552
#49 0x00087d30 in initial_command_loop (load_me=4290564)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/cmdloop.c:313
#50 0x000c21d0 in xemacs_21_5_b28_sparc_sun_solaris2_10 (argc=2,
argv=0xffbfef2c, unused_envp=0x0, restart=0)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:2718
#51 0x000c308c in main (argc=2, argv=0xffbfef2c, unused_envp=0xffbfef38)
at /apps/public/XEmacs/src/hg/xemacs-beta/src/emacs.c:3225
(gdb)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:32 a.m.
New subject: [Bug: 21.5-b28] Crash when closing xemacs via window manager
Raymond Toy (RT/EUS) writes:
Without knowing anything about X, the backtrace looks as if xemacs is
trying to redisplay the frame and update the frame title, after the
window has been closed.
That is certainly what is happening. However, XEmacs should not
crash. This kind of thing can always happen because X is designed to
be asynchronous; the client and the server just keep talking at each
other even though they know the other is doing things "behind their
back".
The back trace is also different if I click on the splash screen to
get
rid of it and then close the window. This, perhaps, looks a bit better.
The backtrace is appended below.
Thanks! I'll keep looking at all the 'traces to see if I can figure
something out.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:44 p.m.
New subject: [Bug: 21.5-b28] Crash when closing xemacs via window manager
I wonder if this might be related to the crashes reported by Raymond
Toy. Just for the record.
David Smith writes in <87hc9oq3b8.fsf(a)piyo.tok.corp.google.com> on emacs-devel:
Summary: segfault when using XIM with multi-tty on gnu/linux
This is with git commit 36d10c7d (Aug 13, 2008).
Steps to reproduce:
1. start emacs -nw
2. have XIM active for your X session (run scim -d)
3. start X11-capable emacs frame with emacsclient -c
4. close the X11 emacs frame
5. segfault with error
*** glibc detected *** /usr/bin/emacs: corrupted double-linked list: 0x083afdf0 ***
Backtrace:
#0 0xb78575c0 in _XSend () from /usr/lib/libX11.so.6
#1 0xb7857792 in _XFlush () from /usr/lib/libX11.so.6
#2 0xb7830a91 in XFlush () from /usr/lib/libX11.so.6
#3 0xb7882160 in ?? () from /usr/lib/libX11.so.6
#4 0xb78818d2 in _XimFlush () from /usr/lib/libX11.so.6
#5 0xb7872618 in ?? () from /usr/lib/libX11.so.6
#6 0xb785d134 in XCloseIM () from /usr/lib/libX11.so.6
#7 0x080d34ed in x_delete_display (dpyinfo=0x942dba0) at xterm.c:8315
#8 0x080d35ea in x_delete_terminal (terminal=0x942dd58) at xterm.c:10650
#9 0x080ca538 in Fdelete_terminal (terminal=155376988, force=137841993) at
terminal.c:334
#10 0x08063e0f in Fdelete_frame (frame=155892172, force=137841993) at frame.c:1512
#11 0x08180d4d in Ffuncall (nargs=1, args=0xbf808ee0) at eval.c:3045
#12 0x0817de71 in Fcall_interactively (function=137877289, record_flag=137841945,
keys=137880348) at callint.c:857
#13 0x08180d34 in Ffuncall (nargs=4, args=0xbf809090) at eval.c:3048
#14 0x08180e89 in call3 (fn=138006169, arg1=137877289, arg2=137841945, arg3=137841945) at
eval.c:2872
#15 0x0812743e in command_loop_1 () at keyboard.c:1879
#16 0x0817f5d0 in internal_condition_case (bfun=0x81270e0 <command_loop_1>,
handlers=137885153,
hfun=0x8122060 <cmd_error>) at eval.c:1511
#17 0x08121473 in command_loop_2 () at keyboard.c:1338
#18 0x0817f6aa in internal_catch (tag=137881129, func=0x8121450 <command_loop_2>,
arg=137841945) at eval.c:1247
#19 0x08121ec7 in command_loop () at keyboard.c:1317
#20 0x0812223b in recursive_edit_1 () at keyboard.c:942
#21 0x08122371 in Frecursive_edit () at keyboard.c:1004
#22 0x08116ffc in main (argc=2, argv=0xbf809744) at emacs.c:1689
Analysis:
Is the call to XCloseIM() in xim_close_dpy (xterm.c:8316) necessary?
Since if we HAVE_X11R6_XIM, xim_destroy_callback is called, and it
claims there is no need to call XCloseIM (xterm.c:8143). A small patch
is attached that changes the logic of xim_close_dpy slightly to call
XCloseIM iff HAVE_XIM && !HAVE_X11R6_XIM. This fixes the segfault here.
Cheers,
- dds
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7 p.m.
New subject: [Bug: 21.5-b28] Crash when closing xemacs via window manager
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> Raymond Toy (RT/EUS) writes:
> Without knowing anything about X, the backtrace looks as if
xemacs is
> trying to redisplay the frame and update the frame title, after the
> window has been closed.
Stephen> That is certainly what is happening. However, XEmacs should not
Stephen> crash. This kind of thing can always happen because X is designed to
Stephen> be asynchronous; the client and the server just keep talking at each
Stephen> other even though they know the other is doing things "behind their
Stephen> back".
> The back trace is also different if I click on the splash screen
to get
> rid of it and then close the window. This, perhaps, looks a bit better.
> The backtrace is appended below.
Stephen> Thanks! I'll keep looking at all the 'traces to see if I can
figure
Stephen> something out.
Some additional information....
I happened to have an old Linux build from Oct 24 2007. Not sure
exactly what version, but when I run that version and close the window
via the window manager, xemacs doesn't crash. But I rebuilt the
current code (same cvs/hg version as used for these reports), I also
get a crash. (In case it matters, the display is still to my Sun box.)
I guess that tells us that something changed between Oct 2007 and
now. Of course, that was almost a year ago, so this might not be
particularly helpful, but at least we know that this crash is
something relatively new.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5733
days inactive
5740
days old
5 comments
2 participants
participants (2)
-
Raymond Toy -
Stephen J. Turnbull