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 _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
