On 21 May 2015, at 1:33 am, Graham Cox graham@bigpond.com wrote:
I can’t do a ‘po self’, even just typing it in, at this point, no matter how
cunning I am at breaking at the right time. It seems as if there really isn’t
enough info to resolve ‘self’ (the message is error: use of
On May 21, 2015, at 00:18 , Graham Cox graham@bigpond.com wrote:
How did you determine that it’s this property that is stale?
Er, I think it was a deduction. The crash occurs during traversal of the
responder chain (apparently), and it’s got as far as the window controller
without
On 21 May 2015, at 5:45 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On May 21, 2015, at 00:18 , Graham Cox graham@bigpond.com wrote:
How did you determine that it’s this property that is stale?
Er, I think it was a deduction.
Ah, fair enough. It was my deduction
On 21 May 2015, at 2:41 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
It looks to me like the problem is that the NSWindowController’s “document”
property is still set to the NSDocument object that was just deallocated
How did you determine that it’s this property that
On May 21, 2015, at 01:33 , Graham Cox graham@bigpond.com wrote:
Therefore either the crash is not due to window.windowController.document
being stale after all,
According to Instruments, there’s only one NSWindow object ever been allocated,
and only one NSWindowController, and both
On 21 May 2015, at 8:09 pm, Graham Cox graham@bigpond.com wrote:
And just to verify this finding, if I add a -prepareSavePanel: method to my
simple test app, I can reproduce the identical crash there. I’m thinking that
could be worth a radar, because it’s pretty easy to forget to
On 21 May 2015, at 7:31 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
However, there is actually one more possibility: window.delegate. If that’s
set to the document rather than the window controller, I suppose that might
account for the crash. But I can’t imagine it
On 22 May 2015, at 3:14 am, Jens Alfke j...@mooseyard.com wrote:
Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment”
sketch:
Spring Surprise: Pop one in your mouth and steel bolts plunge straight through
both cheeks!
—Graham
On May 21, 2015, at 9:51 AM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
5 AppKit +[NSSavePanel _crunchyRawUnbonedPanel]
The only way it could be any better is if it were huggable, too.
Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment”
On May 21, 2015, at 03:09 , Graham Cox graham@bigpond.com wrote:
So it looks as if the mystery is solved
Yes. The funny thing is that I could have sworn that NSSavePanel wasn’t a
NSWindow subclass, but of course it is.
The other funny thing is that if you look in your Instruments data
On Tue, May 19, 2015, at 09:26 PM, Graham Cox wrote:
Crashed Thread:0 Dispatch queue: com.apple.main-thread
Exception Type:EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0
On May 20, 2015, at 21:53 , Graham Cox graham@bigpond.com wrote:
I presume because the document owns its window controllers this must be weak
to avoid a retain cycle.
That was my first thought, too, but then I realized that closing a document
causes the ‘windowControllers’ array to be
On 20 May 2015, at 2:54 pm, Ken Thomases k...@codeweavers.com wrote:
At line 2, it’s clearly trying to access a NSWindow zombie.
I'm not sure that's true. I think if the window were the zombie, the crash
would not show a frame in an NSWindow method, it would occur at the point
where
On 21 May 2015, at 12:42 pm, Graham Cox graham@bigpond.com wrote:
I was able to record the problem running the app this way. That’s the good
news. The bad news is that I’m not really any the wiser. NSDocument is a
complex object that has become somewhat intractable of late. While I
On 21 May 2015, at 2:41 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
It looks to me like the problem is that the NSWindowController’s “document”
property is still set to the NSDocument object that was just deallocated. I'm
surprised to see that the “document” property
On May 20, 2015, at 19:42 , Graham Cox graham@bigpond.com wrote:
or even just offer some general advice how to proceed
It looks to me like the problem is that the NSWindowController’s “document”
property is still set to the NSDocument object that was just deallocated. I'm
surprised to
On May 19, 2015, at 9:26 PM, Graham Cox graham@bigpond.com wrote:
Just to be clear: it crashes when there is no involvement of my code at all -
this is the stack trace without the override, but with zombies enabled:
Crashed Thread:0 Dispatch queue: com.apple.main-thread
On 20 May 2015, at 12:15 pm, Graham Cox graham@bigpond.com wrote:
'd start by looking at frame #4.
The only code of mine involved is at line 4 which is where I overrode
targetForAction:to:from to see what was being called from where, and then
calls super.
Just to be clear:
On 20 May 2015, at 12:09 pm, Kyle Sluder k...@ksluder.com wrote:
On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote:
3 com.apple.AppKit0x7fff8fb2fe3e
-[NSApplication targetForAction:to:from:] + 329
4 com.mapdiva.as.artboard 0x000105a3103a
I’m noticing something odd. When NSFontPanel is visible, it calls
-[NSApplication targetForAction:to:from:] excessively often - in fact on every
movement of the mouse. The action is -validModesForFontPanel: and the target is
nil, so this is being pushed up the responder chain all of the time.
On 20 May 2015, at 10:22 am, Graham Cox graham@bigpond.com wrote:
*this is the theory I’m working on, though it’s hard to be sure. Note that
turning on NSZombies doesn’t show what the original target of the call was -
it still crashes in the same way.
This is wrong - NSZombies does
On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote:
3 com.apple.AppKit0x7fff8fb2fe3e
-[NSApplication targetForAction:to:from:] + 329
4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 +
487482
5 com.apple.AppKit
22 matches
Mail list logo
