Tips for debugging EXC_BAD_ACCESS

[Jacob Carlborg]

On 2012-10-11 20:19, Michel Fortin wrote:

> Most likely, the object objc_msgSend is called on has been deallocated,
> which would mean that windowSendEvent is called with a deallocated
> NSWindow object as its first argument.

How can I detect that? Can I use the object somehow and try to get the 
crash inside my own code instead of in system function?

> I don't know how DWT works, but I'd say there's something amiss with how
> DWT is retaining its NSWindow.

Ok, I'll have a look at this.

If I understand it correctly, it works something like this:

* DWT creates a couple of subclasses
* DWT creates a native window
* Sets up an event loop
* Fetches the next native event
* Translate it into a DWT event
* Calls any handlers
* Pass the native event to the super class

> Since you're on OS X, I'd suggest you try using Instruments to track the
> reference counters of all Objective-C objects within your program until
> it crashes, then search back the history for all
> retain/release/autorelease calls made to the address the EXEC_BAD_ACCESS
> happens on.

I tried using Instruments but I'm barely know what I'm doing. I tried 
with the "leaks" profile but I could really find anything/didn't really 
know how to use it.

It also crashes so fast that Instruments barely has a chance of 
collection any data.

-- 
/Jacob Carlborg