> 28 __XReply + 512 (in libX11.6.dylib) [0x6d50c0] > ... > 11 __XReply + 240 (in libX11.6.dylib) > [0x6d4fb0]
I just took a quick look at xcb_io.c to see what _XReply is doing, and I doubt that it is reentrant. The only way to break out of that "while(1)" loop is if "req == current". I wonder why the test at the top: if(dpy->flags & XlibDisplayIOError) return 0; did not work. Pat --- On Sat, Jan 29, 2011 at 11:54 AM, Jeremy Huddleston <jerem...@apple.com> wrote: > I'm trying to figure out a spin that an XQuartz user reported seeing in > emacs. The problem seems to boil down to two things: > > 1) XLoadQueryFont() is erroring for some reason (probably related to > https://bugs.freedesktop.org/show_bug.cgi?id=28803) > > 2) emacs' error handler seems bugged. Is it legal to call XSync() within the > error handler? It certainly seems like it shouldn't. Did we used to > actually support this with the xtrans version of libX11? > > Why are we spinning in _XReply rather than entering a deadlock here? It > seems to me that we shouldn't wake from this ConditionWait because the > _XReply we're nested in won't ever ConditionBroadcast()... so why is he > seeing us spin through _XReply? It's almost as if this ConditionWait() is a > no-op: > > while(1) > { > PendingRequest *req = dpy->xcb->pending_requests; > xcb_generic_reply_t *response; > > if(req != current && req->reply_waiter) > { > ConditionWait(dpy, dpy->xcb->reply_notify); > /* Another thread got this reply. */ > continue; } > > > Here's the top of the backtrace: > > 28 _XtCreateWidget + 168 (in libXt.6.dylib) [0x569288] > 28 __XtCreateWidget + 700 (in libXt.6.dylib) [0x5691cc] > 28 _xtCreate + 372 (in libXt.6.dylib) [0x568b14] > 28 __XtGetResources + 324 (in libXt.6.dylib) [0x582124] > 28 _GetResources + 2368 (in libXt.6.dylib) [0x581a60] > 28 __XtConvert + 844 (in libXt.6.dylib) [0x562f2c] > 28 _CallConverter + 872 (in libXt.6.dylib) [0x562958] > 28 _XtCvtStringToFontStruct + 156 (in libXt.6.dylib) [0x56592c] > 28 _XLoadQueryFont + 424 (in libX11.6.dylib) [0x6b2dd8] > 28 __XQueryFont + 228 (in libX11.6.dylib) [0x6b1b74] > 28 __XReply + 512 (in libX11.6.dylib) [0x6d50c0] > 28 _handle_response + 148 (in libX11.6.dylib) [0x6d45e4] > 28 _handle_error + 136 (in libX11.6.dylib) [0x6d42f8] > 28 __XError + 264 (in libX11.6.dylib) [0x6d7b38] > 28 _x_error_handler + 84 (in emacs-24.0.50.1) > [0x105444] > 28 _x_error_quitter + 112 (in emacs-24.0.50.1) > [0x1053d0] > 28 _x_connection_closed + 252 (in > emacs-24.0.50.1) [0x10500c] > 28 _XSync + 160 (in libX11.6.dylib) > [0x6d00a0] > 11 __XReply + 240 (in libX11.6.dylib) > [0x6d4fb0] > 5 __XReply + 236 (in libX11.6.dylib) > [0x6d4fac] > 5 __XReply + 248 (in libX11.6.dylib) > [0x6d4fb8] > 3 __XReply + 224 (in libX11.6.dylib) > [0x6d4fa0] > 3 __XReply + 228 (in libX11.6.dylib) > [0x6d4fa4] > 1 __XReply + 252 (in libX11.6.dylib) > [0x6d4fbc] > > > > On Jan 29, 2011, at 02:23, Peter Dyballa wrote: > >> >> Am 29.01.2011 um 05:50 schrieb Jeremy Huddleston: >> >>> Ok, well give me a spindump when your libXaw3d version is in this state. >> >> >> Here it is: >> >> <emacs-24.0.50.1_26454.sample.txt> >> >> -- >> Greetings >> >> Pete >> >> Inside every small problem is a large problem struggling to get out. >> – Second Law of Blissful Ignorance >> > > _______________________________________________ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel