Spinning in _XReply

[Jeremy Huddleston]

So... what should we do about this?  I just got another report about IDL not working with the new libX11 (http://xquartz.macosforge.org/trac/ticket/469), and my hunch is that the user will provide me with a spindump that points to this issue again.


On Jan 29, 2011, at 19:24, Pat Kane wrote:

>>                  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 <jeremyhu at 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 at 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 at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel