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
