On 21 May 2015, at 1:33 am, Graham Cox 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 undeclared
> identifier ‘s
> On 22 May 2015, at 3:14 am, Jens Alfke 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
> 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”
sketch:
Inspector: People won't ex
On May 21, 2015, at 03:09 , Graham Cox 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 for the
allocation eve
> On 21 May 2015, at 8:09 pm, Graham Cox 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 remove that
> referen
> On 21 May 2015, at 7:31 pm, Quincey Morris
> 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 would be.
Well, I was going to
On May 21, 2015, at 01:33 , Graham Cox 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 were created when the d
> On 21 May 2015, at 5:45 pm, Quincey Morris
> wrote:
>
> On May 21, 2015, at 00:18 , Graham Cox 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 as well, but I thought you’d arrived there
by
On May 21, 2015, at 00:18 , Graham Cox 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 crashing, and the document
> On 21 May 2015, at 2:41 pm, Quincey Morris
> 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 is stale? The stack trace
inclu
On May 20, 2015, at 21:53 , Graham Cox 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 emptied, which would
> On 21 May 2015, at 2:41 pm, Quincey Morris
> 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 is ‘assign’ rather than
> ‘str
On May 20, 2015, at 19:42 , Graham Cox 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 see that the “document”
> On 21 May 2015, at 12:42 pm, Graham Cox 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 see the
> same stac
> On 20 May 2015, at 2:54 pm, Ken Thomases 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 that method wa
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
On May 19, 2015, at 9:26 PM, Graham Cox 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
>
> Exception Type:
> On 20 May 2015, at 12:15 pm, Graham Cox 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: it crashes
> On 20 May 2015, at 12:09 pm, Kyle Sluder 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 0x1059ba000 +
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.AppKit0x7ff
> On 20 May 2015, at 10:22 am, Graham Cox 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 make it crash diff
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.
T
22 matches
Mail list logo
