> 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 <[email protected]> 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
>>
>
> _______________________________________________
> [email protected]: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
