[Xquartz-dev] quartz-wm goes crazy on macbook air

Jeremy Huddleston jeremyhu at apple.com
Thu Apr 7 15:38:59 PDT 2011


On Apr 7, 2011, at 2:20 PM, Ken Thomases wrote:

> On Apr 7, 2011, at 11:46 AM, Jeremy Huddleston wrote:
> 
>> On Apr 7, 2011, at 9:16 AM, Jeremy Huddleston wrote:
>> 
>>> The "going crazy" is not a bug in quartz-wm.  What version of the OS are you on?
>>> 
>>> I'm curious how quartz-wm got into that state though.  It's in an error handler, so it didn't like something it got from the server.
>> 
>> So this is a bit confusing.  The x_init_error_handler is only the error handler for a short period of time *before* we enter the CFRunLoop.  Furthermore, it is set via XSetErrorHandler, not XSetIOErrorHandler ... so we should never be calling into x_init_error_handler from XIOError, and we should never be calling into that handler from within the CFRunLoop.
>> 
>> This is a very puzzling backtrace...
> 
> The above sounds like "sample" misattributing a code address to the wrong symbol because the right symbol has been stripped.  Unfortunately, it takes some sleuthing in the assembly code to figure out the real stack trace, if it's even possible.

Right.  But without a stackshot, I don't really know the offsets from those symbols, so I'm stuck with intuition.  We certainly are in the CFRunLoop, so I trust that.  Furthermore, x_init_error_handler is very small, and there is another unstripped symbol *right* after it in the assembly, so I trust that as well... but both can't be correct... there's always a possibility of stack corruption, but I don't see any real evidence of that.  I'm just going to chalk this backtrace up to a bizarre mystery and move on.  The reentrancy issue is fixed, and if the instigating bug comes back, we will hopefully have a better backtrace to work from.

--Jeremy



More information about the Xquartz-dev mailing list