> On Dec 18, 2015, at 7:44 PM, Uli Kusterer <[email protected]> > wrote: > > On 18 Dec 2015, at 17:59, Richard Charles <[email protected]> wrote: >> Debugging a linked library without symbols is difficult (bordering on >> impossible). > > It's not easy, but far from impossible. If you can read assembly, you can > usually figure out quite a lot. The debugger will disassemble stack frames > for you when you step into them. It would be a little easier for Objective-C > code, where all method names are registered publicly, as are class names and > a good part of each object's layout. > > It helps to familiarize oneself with LLDB's commands. Particularly what > registers 64-bit apps use to store parameters and how to print them from > inside a method call, and how the 'po' command works for printing objects.
The difficult thing was that the CGPostError breakpoint stopped at the beginning of the CGPostError function. #0 0x00007fff8e5686c7 in CGPostError () #1 0x00007fff8e568798 in handle_invalid_context () #2 0x00007fff8d5ad2c0 in -[NSView _drawRect:clip:] () At this breakpoint the registers contained passed in parameters for CGPostError () but what was needed was information on -[NSView _drawRect:clip:] (). What would have helped is a conditional symbolic breakpoint after the fact. Break on -[NSView _drawRect:clip:] when followed by a CGPostError with the registers containing the parameters passed into -[NSView _drawRect:clip:]. There are way too many -[NSView _drawRect:clip:] calls to manually step through each one waiting for the one followed by CGPostError. > But for complaints about an invalid context, it sometimes helps to verify > that any API you use from the library this error comes from is documented to > accept NULL where you pass it NULL. And in this case I'd also print the > current CGContext before any calls you make, and ensure that you save and > restore your context before and after any calls where you change it, > especially if you create your own contexts. And ensure that you retain any > contexts that you're keeping around across calls, and verifying that your > window is visible and not deferred if you try to draw in it. (This is all > assuming you're not making a basic mistake like calling drawRect: directly or > (even indirectly) requesting redraws from inside drawRect: I am using an OpenGL context and have checked everything. My actual problem occurs when choosing Revert To > Browse All Versions. > If none of this helps, a common occurrence of weird behaviour like this is > also sometimes screwing up internal state by using thread-safe API that is > not documented to support being used from more than one thread at once, or > API that's not safe to use from non-main threads at all, from several > threads. Any if that ring a bell? I put the application into single threaded mode and get the same error. I requested technical support for this issue and was told to file a bug report so we shall see what happens. Thanks for the input. --Richard Charles _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
