Re: Don't you hate it when Appkit crashes?

[Rob Petrovec]

I agree that this is likely not an issue with AppKit or Core Animation.  I’d 
start by search your code for ‘saveDocumentAs:’.  Whatever object that is 
supposed to be getting called on is likely the object that is being smashed.  
You could also try running with the Static Analyzer & Address Sanitizer in 
Xcode and see if it comes up with anything.  Good luck...

—Rob


> On Feb 12, 2016, at 4:13 PM, Quincey Morris 
>  wrote:
> 
> On Feb 12, 2016, at 14:58 , Graham Cox  wrote:
>> 
>> 0   libobjc.A.dylib  0x7fff9673e4dd objc_msgSend + 29
>> 1   com.apple.QuartzCore 0x7fff9550eb45 
>> CA::Layer::setter(unsigned int, _CAValueType, void const*) + 165
> 
> Unfortunately, it’s not obvious that it’s an AppKit-caused crash, or anything 
> other than a memory management bug in your code.
> 
> Think about scenarios. You could have had a reference to an object that you 
> released, causing deallocation. That memory block is re-allocated for 
> something in AppKit, then you accidentally release your unowned reference 
> again. Hilarity pursues.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Quincey Morris]

On Feb 12, 2016, at 22:24 , Graham Cox  wrote:
> 
> It’s deallocated, so AppKit uses that memory for something else. I clobber 
> that memory using a stale reference.
> 
> With zombies, the memory isn’t deallocated, it’s just marked as belonging to 
> a zombie. If I try and access it using a stale reference, I’d get a zombie 
> exception. AppKit can’t obtain the memory allocated to a zombie.

Oh, yeah, never mind.

The other ideas that were chasing around my mind were (a) the possibility that 
CoreAnimation was actually trying to call out to something in your code, or (b) 
CoreAnimation was using a private shortcut path to ‘release’, so the error 
reporting doesn’t mean what it would normally mean. In the latter case, it’s 
not totally impossible that it was after all a zombie object. I don’t think so, 
I’m just advancing the possibility as a way of emphasizing the difficulty of 
assigning blame.

If you have a crash log from when this happened, that seems like something you 
could submit with a bug report. With a prima facie case against CoreAnimation, 
you could make it Apple’s problem to figure out what went wrong.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Graham Cox]

> On 13 Feb 2016, at 4:02 PM, Quincey Morris 
>  wrote:
> 
> I think, in the scenario I described, zombie detection won’t help. It’s not 
> an undead object, but an undead reference.
> 


Not sure I’m understanding the difference. You said:

> You could have had a reference to an object that you released, causing 
> deallocation. That memory block is re-allocated for something in AppKit, then 
> you accidentally release your unowned reference again. Hilarity pursues.

It’s deallocated, so AppKit uses that memory for something else. I clobber that 
memory using a stale reference.

With zombies, the memory isn’t deallocated, it’s just marked as belonging to a 
zombie. If I try and access it using a stale reference, I’d get a zombie 
exception. AppKit can’t obtain the memory allocated to a zombie.

So, it’s possible that I’ve committed a similar error using some arbitrary 
malloc’ed block, but I don’t do that very often, and I’m usually very careful 
about free() - as such things aren’t reference counted the memory management is 
both simpler and usually much more obvious when it’s wrong. Usually such 
allocations are wrapped in an object anyway.

One other thing I have seen that clobbers memory (and is a bugger to find) is 
an incorrect return type from an Obj-C method, e.g. returning a struct when a 
float was expected. I haven’t seen these sorts of errors for years - I think 
the compiler is better than it used to be at flagging mismatches in return 
type. I can’t quite remember how that kind of problem arose actually - 
something to do with return types not being part of a method’s signature, so 
it’s easy for a method that has the same signature as another (but with a 
different return type) to get compiled as the wrong type. Probably grasping at 
straws there…

> even if you don’t think Swift is a superior language

Would never say that. If I could stop fighting fires and having to make a 
living from the code I have, I might find the time to learn it.


—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Quincey Morris]

On Feb 12, 2016, at 19:46 , Graham Cox  wrote:
> 
> I’ve been running with zombies on and this crash occurs still

I think, in the scenario I described, zombie detection won’t help. It’s not an 
undead object, but an undead reference.

It’s also worth noting, though no help at all to you at the moment, that Swift 
objects actually have two reference counts, one for strong references and one 
for non-strong references. Thus, objects aren’t fully deallocated until there 
literally are no references. Of course, referencing an object that has no 
strong references will cause a deliberate crash, but that’s good. You are 
guaranteed that an invalid pointer is reliably invalid.

I recommend Mike Ash’s in-depth investigation into this topic:


https://mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html 


and offer the opinion that even if you don’t think Swift is a superior 
language, it’s aggressively moving in the direction of being a superior 
developer experience.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Charles Srstka]

> On Feb 12, 2016, at 9:46 PM, Graham Cox  wrote:
> 
> 
>> On 13 Feb 2016, at 10:13 AM, Quincey Morris 
>>  wrote:
>> 
>> On Feb 12, 2016, at 14:58 , Graham Cox  wrote:
>>> 
>>> 0   libobjc.A.dylib 0x7fff9673e4dd objc_msgSend + 29
>>> 1   com.apple.QuartzCore0x7fff9550eb45 
>>> CA::Layer::setter(unsigned int, _CAValueType, void const*) + 165
>> 
>> Unfortunately, it’s not obvious that it’s an AppKit-caused crash, or 
>> anything other than a memory management bug in your code.
>> 
>> Think about scenarios. You could have had a reference to an object that you 
>> released, causing deallocation. That memory block is re-allocated for 
>> something in AppKit, then you accidentally release your unowned reference 
>> again. Hilarity pursues.
>> 
> 
> 
> My thoughts exactly, except (I should have mentioned) I’ve been running with 
> zombies on and this crash occurs still (but only once in a blue moon). I 
> guess that still could mean it’s some other memory that’s getting clobbered. 
> The sort of bug I hate, there’s so few ways to get a handle on it.

Is it possible that you might have accidentally accessed something from a 
background thread?

Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Graham Cox]

> On 13 Feb 2016, at 10:13 AM, Quincey Morris 
>  wrote:
> 
> On Feb 12, 2016, at 14:58 , Graham Cox  wrote:
>> 
>> 0   libobjc.A.dylib  0x7fff9673e4dd objc_msgSend + 29
>> 1   com.apple.QuartzCore 0x7fff9550eb45 
>> CA::Layer::setter(unsigned int, _CAValueType, void const*) + 165
> 
> Unfortunately, it’s not obvious that it’s an AppKit-caused crash, or anything 
> other than a memory management bug in your code.
> 
> Think about scenarios. You could have had a reference to an object that you 
> released, causing deallocation. That memory block is re-allocated for 
> something in AppKit, then you accidentally release your unowned reference 
> again. Hilarity pursues.
> 


My thoughts exactly, except (I should have mentioned) I’ve been running with 
zombies on and this crash occurs still (but only once in a blue moon). I guess 
that still could mean it’s some other memory that’s getting clobbered. The sort 
of bug I hate, there’s so few ways to get a handle on it.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Don't you hate it when Appkit crashes?

[Quincey Morris]

On Feb 12, 2016, at 14:58 , Graham Cox  wrote:
> 
> 0   libobjc.A.dylib   0x7fff9673e4dd objc_msgSend + 29
> 1   com.apple.QuartzCore  0x7fff9550eb45 
> CA::Layer::setter(unsigned int, _CAValueType, void const*) + 165

Unfortunately, it’s not obvious that it’s an AppKit-caused crash, or anything 
other than a memory management bug in your code.

Think about scenarios. You could have had a reference to an object that you 
released, causing deallocation. That memory block is re-allocated for something 
in AppKit, then you accidentally release your unowned reference again. Hilarity 
pursues.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com