Spinning in _XReply

[Jeremy Huddleston]

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
>