Re: CGContextClipToRects: invalid context 0x0.
Re: CGContextClipToRects: invalid context 0x0.
- Subject: Re: CGContextClipToRects: invalid context 0x0.
- From: Richard Charles <email@hidden>
- Date: Mon, 21 Dec 2015 13:29:17 -0700
> On Dec 18, 2015, at 7:44 PM, Uli Kusterer <email@hidden> wrote:
>
> On 18 Dec 2015, at 17:59, Richard Charles <email@hidden> 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@hidden)
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:
This email sent to email@hidden