10:51 a.m.
XEmacs 21.4-14 hangs when editres client asks 'Select widget in client'.
XEmacs 21.5 does not hang.
To reproduce.
Start xemacs
$ xemacs-21.4.14 -vanilla
Start editres
$ editres
In editres from menu 'Commands' issue the command 'Get Tree' and click on
XEmacs frame. The editres pane will display the tree of XEmacs widgets.
Then in editres from 'Tree' menu issue the command 'Select Widget in
Client'.
Click on XEmacs toolbar. Editres says that request is sent to the client,
XEmacs hangs, some time after Editres says that "it appears that this client
does not understand the Editres Protocol".
XEmacs prints in the console:
xemacs: X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 1797
Current serial number in output stream: 1798
Attaching to the process with GDB gives the following backtrace:
(gdb) where
#0 0xffffe002 in ?? ()
#1 0x401bfbd7 in _XRead () from /usr/X11R6/lib/libX11.so.6
#2 0x401c071d in _XReply () from /usr/X11R6/lib/libX11.so.6
#3 0x401aa3e7 in XGetWindowAttributes () from /usr/X11R6/lib/libX11.so.6
#4 0x40120c46 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#5 0x40120d0a in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#6 0x40120d56 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#7 0x40120df0 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#8 0x4011f8de in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#9 0x4011f843 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#10 0x40159f88 in XtDisownSelection () from /usr/X11R6/lib/libXt.so.6
#11 0x4015a2bf in XtDisownSelection () from /usr/X11R6/lib/libXt.so.6
#12 0x4014564d in _XtFreeWWTable () from /usr/X11R6/lib/libXt.so.6
#13 0x4014582d in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#14 0x4014625d in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
#15 0x4014657f in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#16 0x4015272b in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#17 0x0823a1e8 in emacs_Xt_next_event (emacs_event=0x85dbcec) at
/localhome/npak/src/xemacs-21.4.14/src/event-Xt.c:2750
#18 0x0811caba in event_stream_next_event (event=0x85dbcec) at
/localhome/npak/src/xemacs-21.4.14/src/event-stream.c:499
#19 0x08125131 in next_event_internal (target_event=140360940, allow_queued=1)
at /localhome/npak/src/xemacs-21.4.14/src/event-stream.c:1960
#20 0x0811e442 in Fnext_event (event=140360940, prompt=1080248156) at
/localhome/npak/src/xemacs-21.4.14/src/event-stream.c:2180
#21 0x080a6728 in Fcommand_loop_1 () at
/localhome/npak/src/xemacs-21.4.14/src/cmdloop.c:574
#22 0x080c61af in condition_case_1 (handlers=1080247796, bfun=0x80a6a00
<command_loop_1>, barg=1080248156, hfun=0x80a6a44 <cmd_error>,
harg=1080248156) at /localhome/npak/src/xemacs-21.4.14/src/eval.c:1652
#23 0x080a6c10 in command_loop_2 (dummy=1080248156) at
/localhome/npak/src/xemacs-21.4.14/src/cmdloop.c:256
#24 0x080c6085 in internal_catch (tag=-514, func=0x80a6bd0 <command_loop_2>,
arg=1080248156, threw=0x0)
at /localhome/npak/src/xemacs-21.4.14/src/eval.c:1318
#25 0x080a61da in initial_command_loop (load_me=-514) at
/localhome/npak/src/xemacs-21.4.14/src/cmdloop.c:305
#26 0x080c312d in xemacs_21_4_14_i686_pc_linux (argc=2, argv=0xbfffdbc4, envp=0xbfffdbd0,
restart=0)
at /localhome/npak/src/xemacs-21.4.14/src/emacs.c:2460
#27 0x080c3b21 in main (argc=-514, argv=0xfffffdfe, envp=0xfffffdfe) at
/localhome/npak/src/xemacs-21.4.14/src/emacs.c:2892
#28 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
-------------------------------------------------------------------------------
XEmacs configuration
uname -a: Linux hookah 2.4.20-28.9 #1 Thu Dec 18 13:45:22 EST 2003 i686 i686 i386
GNU/Linux
/localhome/npak/src/xemacs-21.4.14/configure
'--srcdir=/localhome/npak/src/xemacs-21.4.14'
'--package-path=/usr/local/xemacs/' '--with-x11' '--with-xim=xlib'
'--with-scrollbars=athena' '--with-dialogs=athena'
'--with-widgets=athena' '--with-athena=3d' '--with-mule'
'--with-canna=no' '--with-wnn=no' '--with-pop' '--debug'
'--error-checking=all' '--pdump'
XEmacs 21.4.14 "Reasonable Discussion" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /localhome/npak/src/xemacs-21.4.14
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
-Wmissing-prototypes -Wsign-compare -fno-strict-aliasing -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Athena scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
-------------------------------------------------------------------------------
OS: Redhat 9, XFree 4.3.0, kwin window manager
11:38 a.m.
Nickolay Pakoulin wrote:
XEmacs 21.4-14 hangs when editres client asks 'Select widget in
client'.
XEmacs 21.5 does not hang.
To reproduce.
Start xemacs
$ xemacs-21.4.14 -vanilla
Start editres
$ editres
In editres from menu 'Commands' issue the command 'Get Tree' and click
on
XEmacs frame. The editres pane will display the tree of XEmacs widgets.
Then in editres from 'Tree' menu issue the command 'Select Widget in
Client'.
Click on XEmacs toolbar. Editres says that request is sent to the client,
XEmacs hangs, some time after Editres says that "it appears that this client
does not understand the Editres Protocol".
XEmacs prints in the console:
xemacs: X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 1797
Current serial number in output stream: 1798
Attaching to the process with GDB gives the following backtrace:
(gdb) where
#0 0xffffe002 in ?? ()
#1 0x401bfbd7 in _XRead () from /usr/X11R6/lib/libX11.so.6
#2 0x401c071d in _XReply () from /usr/X11R6/lib/libX11.so.6
#3 0x401aa3e7 in XGetWindowAttributes () from /usr/X11R6/lib/libX11.so.6
#4 0x40120c46 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#5 0x40120d0a in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#6 0x40120d56 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#7 0x40120df0 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#8 0x4011f8de in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#9 0x4011f843 in _XEditResCheckMessages () from /usr/X11R6/lib/libXmu.so.6
#10 0x40159f88 in XtDisownSelection () from /usr/X11R6/lib/libXt.so.6
#11 0x4015a2bf in XtDisownSelection () from /usr/X11R6/lib/libXt.so.6
#12 0x4014564d in _XtFreeWWTable () from /usr/X11R6/lib/libXt.so.6
#13 0x4014582d in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6
#14 0x4014625d in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
#15 0x4014657f in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#16 0x4015272b in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#17 0x0823a1e8 in emacs_Xt_next_event (emacs_event=0x85dbcec) at
/localhome/npak/src/xemacs-21.4.14/src/event-Xt.c:2750
[snip]
I get the same result here (BadWindow error for X_GetWindowAttributes,
XEmacs hangs).
However, I note that it only applies to the toolbar. Selecting
scrollbars or the EmacsFrame widget works correctly. Selecting the
menu bar identifies the Shell rather than the menu bar itself, but
doesn't hang.
Also, I have a more informative backtrace (my X libs have debug info):
#0 0x405200de in __select () from /lib/libc.so.6
#1 0x40383d2c in __DTOR_END__ () from /usr/X11R6/lib/libX11.so.6
#2 0x402f6c67 in _XRead (dpy=0x864f0b0, data=0xbfffbb9c "\n\003r\006.",
size=32) at XlibInt.c:1037
#3 0x402f76a3 in _XReply (dpy=0x864f0b0, rep=0xbfffbb9c, extra=0, discard=1)
at XlibInt.c:1672
#4 0x402e2f32 in XGetWindowAttributes (dpy=0x864f0b0, w=0, attr=0xbfffbbe8)
at GetWAttrs.c:113
#5 0x40263073 in PositionInChild (child=0x87469a0, x=368, y=41)
at EditresCom.c:1351
#6 0x40263127 in _FindChild (parent=0x86fd658, x=368, y=41)
at EditresCom.c:1384
#7 0x402631cb in DoFindChild (w=0x86fc158, event=0x86edde8, stream=0x4026c894)
at EditresCom.c:1429
#8 0x4026210b in ExecuteCommand (w=0x86fc158, sel=405, ident=2 '\002',
event=0x86edde8) at EditresCom.c:534
#9 0x4026200a in GetCommand (w=0x86fc158, data=0x2, selection=0xbfffdda0,
type=0xbfffdd70, value=0x86eddc8, length=0xbfffdd78, format=0xbfffdd74)
at EditresCom.c:461
#10 0x40296afa in HandleNormal (dpy=0x864f0b0, widget=0x86fc158, property=274,
info=0x87080a0, closure=0x2, selection=405) at Selection.c:1310
#11 0x40296df1 in HandleSelectionReplies (widget=0x86fc158, closure=0x87080a0,
ev=0xbfffdfc8, cont=0xbfffde0f "\001") at Selection.c:1408
#12 0x4028515b in CallEventHandlers (widget=0x86fc158, event=0xbfffdfc8,
mask=2147483648) at Event.c:841
#13 0x402853a2 in XtDispatchEventToWidget (widget=0x86fc158, event=0xbfffdfc8)
at Event.c:952
#14 0x40285c15 in _XtDefaultDispatcher (event=0xbfffdfc8) at Event.c:1417
#15 0x40285f5d in XtDispatchEvent (event=0xbfffdfc8) at Event.c:1497
#16 0x40290787 in XtAppProcessEvent (app=0x838d778, mask=1) at NextEvent.c:1407
#17 0x081e43b5 in emacs_Xt_next_event (emacs_event=0x86d4074)
at event-Xt.c:2725
Note that frame #4 has w=0, which explains the BadWindow error. The
code corresponding to frame #5 is:
if (XtIsWidget(child) && !(mapped_when_managed && XtIsManaged(child)))
{
XWindowAttributes attrs;
if (XGetWindowAttributes(XtDisplay(child), XtWindow(child), &attrs)
&& attrs.map_state != IsViewable)
return (False);
}
So, we appear to have a valid widget with no window. Which widget?
print *child
$2 = {core = {self = 0x87469a0, widget_class =
0x8253d80, parent = 0x86fd658,
xrm_name = 1486, being_destroyed = 0 '\000',
destroy_callbacks = 0x8712b10, constraints = 0x0, x = 0, y = 0,
width = 25, height = 12, border_width = 0, managed = 0 '\000',
sensitive = 1 '\001', ancestor_sensitive = 1 '\001', event_table =
0x0,
tm = {translations = 0x8746778, proc_table = 0x0, current_state = 0x0,
lastEventTime = 0}, accelerators = 0x0, border_pixel = 0,
border_pixmap = 2, popup_list = 0x0, num_popups = 0,
name = 0x8702cae "scrollbar_65539", screen = 0x86aadf0, colormap = 32,
window = 0, depth = 16, background_pixel = 52857, background_pixmap = 2,
visible = 1 '\001', mapped_when_managed = 1 '\001'}}
I.e. "scrollbar_65539".
There are two scrollbars; 65538 is the vertical one (width = 15,
height = 895), so 65539 must be the horizontal one. But the horizontal
one isn't displayed unless truncate-lines is t. Presumably it's being
created at startup but not realised until necessary.
Personally, I consider this to be a bug in libXmu; it ought to be
calling XtIsRealized() on the widget before trying to use its window.
Also, I'm not sure how much XEmacs can do about it, given that the
last XEmacs function in the backtrace is XtDispatchEvent().
OTOH, win light of both this and the SelectionRequest/BadWindow hangs,
I'm starting to suspect a flaw in the X error handler (OTOH, it
doesn't help that the "officially" correct behaviour for error
handlers involves terminating the application).
--
Glynn Clements <glynn.clements(a)virgin.net>
11:50 a.m.
>>>> "Glynn" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
Glynn> Nickolay Pakoulin wrote:
> XEmacs 21.4-14 hangs when editres client asks 'Select widget
in
> client'. XEmacs 21.5 does not hang.
> XEmacs prints in the console:
> xemacs: X Error of failed request: BadWindow (invalid Window
> parameter)
Glynn> I get the same result here (BadWindow error for
Glynn> X_GetWindowAttributes, XEmacs hangs).
Now this is interesting. Glynn, so you think there's a chance that
this is a repeatable instance of whatever it is that causes the
intermittent BadWindow bugs we see?
What options do we have? Our own error handler? Can we force the
widget to be realized and just not map/manage it?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:25 p.m.
Stephen J. Turnbull wrote:
Glynn> Nickolay Pakoulin wrote:
>> XEmacs 21.4-14 hangs when editres client asks 'Select widget in
>> client'. XEmacs 21.5 does not hang.
>> XEmacs prints in the console:
>> xemacs: X Error of failed request: BadWindow (invalid Window
>> parameter)
Glynn> I get the same result here (BadWindow error for
Glynn> X_GetWindowAttributes, XEmacs hangs).
Now this is interesting. Glynn, so you think there's a chance that
this is a repeatable instance of whatever it is that causes the
intermittent BadWindow bugs we see?
My suspicion is that there is a problem with error handling.
E.g. in this instance, XGetWindowAttributes never returns. It's
blocking in _XReply(), presumably waiting for the X server to send it
the window's attributes. But XGetWindowAttributes() does appear to
allow for _XReply() failing, and _XReply() handles X_Error packets.
What options do we have? Our own error handler?
We already have that. The default X error handler just prints the
message then calls exit(). Ours doesn't do appear to do much more, but
it uses stderr_out, and I'm wondering if that is doing something
illegal (e.g. inadvertantly calling X functions).
Can we force the
widget to be realized and just not map/manage it?
Probably.
But it would be useful to get to the bottom of the general
error-handling problems.
--
Glynn Clements <glynn.clements(a)virgin.net>
6:34 p.m.
Glynn Clements wrote:
> >> XEmacs 21.4-14 hangs when editres client asks
'Select widget in
> >> client'. XEmacs 21.5 does not hang.
> >> XEmacs prints in the console:
> >> xemacs: X Error of failed request: BadWindow (invalid Window
> >> parameter)
>
> Glynn> I get the same result here (BadWindow error for
> Glynn> X_GetWindowAttributes, XEmacs hangs).
>
> Now this is interesting. Glynn, so you think there's a chance that
> this is a repeatable instance of whatever it is that causes the
> intermittent BadWindow bugs we see?
My suspicion is that there is a problem with error handling.
E.g. in this instance, XGetWindowAttributes never returns. It's
blocking in _XReply(), presumably waiting for the X server to send it
the window's attributes. But XGetWindowAttributes() does appear to
allow for _XReply() failing, and _XReply() handles X_Error packets.
> What options do we have? Our own error handler?
We already have that. The default X error handler just prints the
message then calls exit(). Ours doesn't do appear to do much more, but
it uses stderr_out, and I'm wondering if that is doing something
illegal (e.g. inadvertantly calling X functions).
More evidence in support of that suspicion: if I run XEmacs under gdb,
and make x_error_handler() return immediately, the problem vanishes.
Single stepping through various bits of code which I don't pretend to
understand, I managed to end up here:
event-Xt.c:
2876 XEventsQueued (display, QueuedAfterReading);
2877 queued = XCheckIfEvent (display, &event,
2878 quit_char_predicate,
2879 (char *) &critical_quit);
#0 emacs_Xt_quit_p () at event-Xt.c:2876
#1 0x08119632 in event_stream_quit_p () at event-stream.c:596
#2 0x081c230a in check_quit () at signal.c:513
#3 0x080cd55e in unbind_to_hairy (count=7) at eval.c:4973
#4 0x080ccfb2 in unbind_to (count=7, value=
{gu = {type = Lisp_Type_Record, val = 34234677}, s = {bits = 0, val = 68469354}, u =
{bits = 0, val = 68469354}, ui = 136938708, i = 136938708, v = 0x82984d4, cv = 0x82984d4})
at eval.c:4959
#5 0x08091cb6 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA,
source=0xbfff96d8, coding_system=
{gu = {type = Lisp_Type_Record, val = 34371126}, s = {bits = 0, val = 68742252}, u =
{bits = 0, val = 68742252}, ui = 137484504, i = 137484504, v = 0x831d8d8, cv = 0x831d8d8},
sink_type=DFC_TYPE_DATA, sink=0xbfff96d0)
at buffer.c:1948
#6 0x0818c112 in std_handle_out_va (stream=0x405699c0,
fmt=0x82410e5 "\n%s: ", args=0xbfffb744) at print.c:186
#7 0x0818c179 in stderr_out (fmt=0x82410e5 "\n%s: ") at print.c:208
#8 0x081de990 in x_error_handler (disp=0x865e790, event=0xbfffb770)
at device-x.c:1060
#9 0x40300801 in _XError (dpy=0x865e790, rep=0xbfffb890) at XlibInt.c:2898
(More stack frames follow...)
So, x_error_handler ends up checking for quit, which involves calling
X functions, which isn't permitted inside an X error handler.
Note: the entire reason why x_error_handler() calls stderr_out() is so
that it can prefix the default Xmu error message with the program
name:
stderr_out ("\n%s: ",
(STRINGP (Vinvocation_name)
? (char *) XSTRING_DATA (Vinvocation_name)
: "xemacs"));
XmuPrintDefaultErrorMessage (disp, event, stderr);
If I disable the call to stderr_out, the problem goes away. I still
see the BadWindow error, but it doesn't cause XEmacs to hang.
--
Glynn Clements <glynn.clements(a)virgin.net>
--- src/device-x.c~ Wed Aug 21 23:59:00 2002
+++ src/device-x.c Fri Jan 30 18:21:45 2004
＠＠ -1057,10 +1057,14 ＠＠
}
#endif /* EXTERNAL_WIDGET */
+#if 0
+ /* This ends up calling X, which isn't allowed in an X error handler
+ */
stderr_out ("\n%s: ",
(STRINGP (Vinvocation_name)
? (char *) XSTRING_DATA (Vinvocation_name)
: "xemacs"));
+#endif
XmuPrintDefaultErrorMessage (disp, event, stderr);
}
return 0;
6:31 a.m.
OK, I think we need to fix stderr_out. It should not be calling X.
What do you say, Ben?
Glynn Clements wrote:
> >> XEmacs 21.4-14 hangs when editres client asks
'Select widget in
> >> client'. XEmacs 21.5 does not hang.
> >> XEmacs prints in the console:
> >> xemacs: X Error of failed request: BadWindow (invalid Window
> >> parameter)
>
> Glynn> I get the same result here (BadWindow error for
> Glynn> X_GetWindowAttributes, XEmacs hangs).
>
> Now this is interesting. Glynn, so you think there's a chance that
> this is a repeatable instance of whatever it is that causes the
> intermittent BadWindow bugs we see?
My suspicion is that there is a problem with error handling.
E.g. in this instance, XGetWindowAttributes never returns. It's
blocking in _XReply(), presumably waiting for the X server to send it
the window's attributes. But XGetWindowAttributes() does appear to
allow for _XReply() failing, and _XReply() handles X_Error packets.
> What options do we have? Our own error handler?
We already have that. The default X error handler just prints the
message then calls exit(). Ours doesn't do appear to do much more, but
it uses stderr_out, and I'm wondering if that is doing something
illegal (e.g. inadvertantly calling X functions).
More evidence in support of that suspicion: if I run XEmacs under gdb,
and make x_error_handler() return immediately, the problem vanishes.
Single stepping through various bits of code which I don't pretend to
understand, I managed to end up here:
event-Xt.c:
2876 XEventsQueued (display, QueuedAfterReading);
2877 queued = XCheckIfEvent (display, &event,
2878 quit_char_predicate,
2879 (char *) &critical_quit);
#0 emacs_Xt_quit_p () at event-Xt.c:2876
#1 0x08119632 in event_stream_quit_p () at event-stream.c:596
#2 0x081c230a in check_quit () at signal.c:513
#3 0x080cd55e in unbind_to_hairy (count=7) at eval.c:4973
#4 0x080ccfb2 in unbind_to (count=7, value=
{gu = {type = Lisp_Type_Record, val = 34234677}, s = {bits = 0, val = 68469354}, u =
{bits = 0, val = 68469354}, ui = 136938708, i = 136938708, v = 0x82984d4, cv = 0x82984d4})
at eval.c:4959
#5 0x08091cb6 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA,
source=0xbfff96d8, coding_system=
{gu = {type = Lisp_Type_Record, val = 34371126}, s = {bits = 0, val = 68742252}, u =
{bits = 0, val = 68742252}, ui = 137484504, i = 137484504, v = 0x831d8d8, cv = 0x831d8d8},
sink_type=DFC_TYPE_DATA, sink=0xbfff96d0)
at buffer.c:1948
#6 0x0818c112 in std_handle_out_va (stream=0x405699c0,
fmt=0x82410e5 "\n%s: ", args=0xbfffb744) at print.c:186
#7 0x0818c179 in stderr_out (fmt=0x82410e5 "\n%s: ") at print.c:208
#8 0x081de990 in x_error_handler (disp=0x865e790, event=0xbfffb770)
at device-x.c:1060
#9 0x40300801 in _XError (dpy=0x865e790, rep=0xbfffb890) at XlibInt.c:2898
(More stack frames follow...)
So, x_error_handler ends up checking for quit, which involves calling
X functions, which isn't permitted inside an X error handler.
Note: the entire reason why x_error_handler() calls stderr_out() is so
that it can prefix the default Xmu error message with the program
name:
stderr_out ("\n%s: ",
(STRINGP (Vinvocation_name)
? (char *) XSTRING_DATA (Vinvocation_name)
: "xemacs"));
XmuPrintDefaultErrorMessage (disp, event, stderr);
If I disable the call to stderr_out, the problem goes away. I still
see the BadWindow error, but it doesn't cause XEmacs to hang.
--
Glynn Clements <glynn.clements(a)virgin.net>
--- src/device-x.c~ Wed Aug 21 23:59:00 2002
+++ src/device-x.c Fri Jan 30 18:21:45 2004
＠＠ -1057,10 +1057,14 ＠＠
}
#endif /* EXTERNAL_WIDGET */
+#if 0
+ /* This ends up calling X, which isn't allowed in an X error handler
+ */
stderr_out ("\n%s: ",
(STRINGP (Vinvocation_name)
? (char *) XSTRING_DATA (Vinvocation_name)
: "xemacs"));
+#endif
XmuPrintDefaultErrorMessage (disp, event, stderr);
}
return 0;
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:47 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
OK, I think we need to fix stderr_out. It should not be calling X.
I understand that stderr_out calls something that calls QUIT, which in
turn calls X.
If the X connection is in an unusable state, we should mark it as
such, so that asynchronous code, such as QUIT, knows not to use it.
3:02 a.m.
probably the easiest thing to do is bracket the code that puts the X connection
in an unusable state using begin_dont_check_for_quit(). that's the purpose of
this call.
----- Original Message -----
From: "Hrvoje Niksic" <hniksic(a)xemacs.org>
To: "Stephen J. Turnbull" <stephen(a)xemacs.org>
Cc: "Glynn Clements" <glynn.clements(a)virgin.net>; <ben(a)666.com>;
"Nickolay
Pakoulin" <npak(a)ispras.ru>; <xemacs-beta(a)xemacs.org>
Sent: Saturday, January 31, 2004 3:47 AM
Subject: Re: [21.4] Hangs when talking with editres
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> OK, I think we need to fix stderr_out. It should not be calling X.
I understand that stderr_out calls something that calls QUIT, which in
turn calls X.
If the X connection is in an unusable state, we should mark it as
such, so that asynchronous code, such as QUIT, knows not to use it.
1:13 p.m.
It seems that xemacs-21.5-b16 does not suffer from it. It does print error
messages but does not hang.
xemacs-21.5-b16: X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 5292
Current serial number in output stream: 5293
Nick.
intro: "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>> "Glynn" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
Glynn> Nickolay Pakoulin wrote:
>> XEmacs 21.4-14 hangs when editres client asks 'Select
widget in client'.
>> XEmacs 21.5 does not hang. XEmacs prints in the console: xemacs: X Error
>> of failed request: BadWindow (invalid Window parameter)
Glynn> I get the same result here (BadWindow error for X_GetWindowAttributes,
Glynn> XEmacs hangs).
SJT> Now this is interesting. Glynn, so you think there's a chance that this
SJT> is a repeatable instance of whatever it is that causes the intermittent
SJT> BadWindow bugs we see?
SJT> What options do we have? Our own error handler? Can we force the
SJT> widget to be realized and just not map/manage it?
SJT> -- Institute of Policy and Planning Sciences
SJT> http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1
SJT> Tsukuba 305-8573 JAPAN Ask not how you can "do" free software
business;
SJT> ask what your business can "do for" free software.
7383
days inactive
7386
days old
8 comments
5 participants
participants (5)
-
Ben Wing -
Glynn Clements -
Hrvoje Niksic -
Nickolay Pakoulin -
Stephen J. Turnbull