Re: App hangs when displaying any sheet in 10.5 [was Re: Where to start looking to fix hang?]
Re: App hangs when displaying any sheet in 10.5 [was Re: Where to start looking to fix hang?]
- Subject: Re: App hangs when displaying any sheet in 10.5 [was Re: Where to start looking to fix hang?]
- From: Graham Cox <email@hidden>
- Date: Thu, 5 Jun 2008 22:52:52 +1000
OK, this is really weird, and frustratingly difficult to get a grip on.
By preventing certain things initialising in my app, I can get sheets
to work. So I'm quite prepared to agree that it's something I'm doing
that is causing some subtle corruption somewhere that just happens to
throw a spanner in the works at this one point.
The trouble is I seem to be chasing phantoms, since in one case I can
prevent the problem simply by commenting out a simple assignment to an
ivar in one of my classes - but there's really nothing wrong with it -
I've n-tuple checked it. (And I know writing that I'm getting a
sinking feeling that no-one will believe me, and want to see the code,
etc, etc). I've moved the ivars around, added some guard values around
it, but nothing makes a difference. But it's almost certainly a red-
herring, because I can find many other ways to get sheets to work by
completely different routes that don't touch this code. The point is,
it's *touchy*. It's hard to pin down because my app is fairly complex
and almost anything I do to try and flush the problem out stops it
initialising in quite major ways, meaning that the culprit could
literally be anywhere. But if it is corruption, it's not major because
the app otherwise is functioning normally - I see no other evidence of
a problem.
Back to basics: seems as if the thread is deadlocked when animating
the sheet (yes? no? is mach_msg_trap anything to do with thread locks,
or am I guessing wrong?). Without looking at the Appkit source I have
no way to tell what lock that's waiting on, so there's no clue there.
However since I'm not using threads or locks in my own code, it
doesn't seem likely to be a real lock state anyway - again I expect
something dodgy in my code has blown away the lock or the code that is
using it. I have no idea how to look for that sort of problem, or what
kind of code might do this (if I were using C arrays, overrunning the
end is pretty common, but I'm only using NSArray and other container
classes). It's like looking for a needle in a haystack.
Can anyone suggest any techniques I might try to help flush this out?
I ran ThreadViewer but I get the same stack trace as shown below.
SpinControl isn't any help because it only lists addresses, not
symbols. But as I'm convinced the problem isn't really here, this
stack trace is no help anyway. Any tools to pick up writing off the
end of an object or other mem allocation?
Graham
On 5 Jun 2008, at 3:07 pm, Graham Cox wrote:
Another example for one of my own sheets, but the hang is in the
same place:
#0 0x94fc54a6 in mach_msg_trap
#1 0x94fccc9c in mach_msg
#2 0x9234f0be in CFRunLoopRunSpecific
#3 0x9234fcf8 in CFRunLoopRunInMode
#4 0x905c7c3f in -[NSMoveHelper _doAnimation]
#5 0x905c6756 in -[NSMoveHelper(NSSheets) _moveParent:andOpenSheet:]
#6 0x905c5f7c in -[NSWindow(NSSheets) _orderFrontRelativeToWindow:]
#7 0x90422465 in -[NSWindow
_reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]
#8 0x904642e7 in -[NSApplication
_orderFrontModalWindow:relativeToWindow:]
#9 0x90463d4f in -[NSApplication
_commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo
:]
#10 0x0001040b in -[GCPolarDuplicateController
beginPolarDuplicationDialog:polarDelegate:] at
GCPolarDuplicateController.m:69
#11 0x000024ee in -[GCOrteliusDocument polarDuplicate:] at
GCOrteliusDocument.m:99
#12 0x90435c23 in -[NSApplication sendAction:to:from:]
[...]
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden