Re: XCode Debugger Breakpoint Question
Re: XCode Debugger Breakpoint Question
- Subject: Re: XCode Debugger Breakpoint Question
- From: Jim Ingham <email@hidden>
- Date: Tue, 26 Apr 2016 12:06:38 -0700
> On Apr 26, 2016, at 11:24 AM, Dave <email@hidden> wrote:
>
> Hi and Thanks Jens,
>
>> On 26 Apr 2016, at 17:58, Jens Alfke <email@hidden> wrote:
>>
>>
>>> On Apr 26, 2016, at 7:28 AM, Dave <email@hidden> wrote:
>>>
>>> I have the “All Objective-C Exceptions” breakpoint enabled. I’m calling a third party method that calls into the Core Foundation layer and this causes an exception. The method handles the exception by using @catch and deals with the problem internally.
>>
>> Yeah, this is a pain. I haven’t run into library code that does this with Obj-C exceptions, but Apple’s Security framework does it with C++ exceptions. It’s a bad idea because (a) throwing exceptions is expensive, (b) exceptions should be used for true failure conditions, not as flow control, and (c) it bollocks up exception breakpoints.
>>
>> Can you fix the 3rd party framework to avoid triggering the exception? Or at least file a bug report?
>
> No, not really it makes some CF calls and they throw, apparently the problem has been reported to Apple and they agree its a bug and their work-around is to catch the exceptions…...
>
>>
>>> My problem is that it is causing the “All Objective-C Exceptions” to trigger which causes a hiccup in my App. I switched it off but now other real exceptions are being ignored too. Is there any way to set it up so that it doesn’t breakpoint on the ones in the Third Party Method but does breakpoint on all others?
>>
>> The only thing I can think of would be to edit the breakpoint and use the ‘Add Action’ button to add some LLDB commands that will tell the debugger to continue if it’s in the 3rd party library. But my knowledge of LLDB commands is at the kindergarten level, so I can’t help you with that :(
>
> The thing is that although I have the 3rd party framework as a separate .framework bundle, I am at the moment including the project as a sub-probject of my project, so I have the source inline.
>
> It may be that if it were in a third party framework that it would be ok.
>
> I had thought that there was a option to only trigger the breakpoint if the exception is uncaught, which in this case it *is* caught, but that option seems to have disappeared.
Not in lldb or gdb before it. I have various bugs to add filtering by thrown object, and figuring out whether/where the exception will get caught, but that's still work to do...
However, what you really want to do is check the objc_exception_throw's caller and if it (or something above it depending on how exactly this happens) is CoreFoundation, then you tell the breakpoint to continue.
This isn't that hard to do using the Python breakpoint commands. Make a Python file somewhere (say breakpoint_filters.py)
$ cat ~/breakpoint_filters.py
def reject_by_parent_name (frame, bp_loc, dict):
caller = frame.parent
if caller.IsValid():
if "BadFunc" in caller.name:
return False
return True
Then run your project, for instance do:
(lldb) break set -E objc
(lldb) commmand script import ~/breakpoint_filters.py
(lldb) break command add -F breakpoint_filters.reject_by_parent_name
Then in this trivial case, if the caller of your breakpoint has "BadFunc" in the name, the breakpoint will auto-continue.
You can keep calling parent to trace up the stack however high you need to go to find the CoreFoundation caller you are trying to block. Or you can get the frames array from:
frames = frame.thread.frames
then frames[0] is the youngest frame, frames[1] its caller, and so on.
You can also check the shared library for the code in a given frame:
frame.module.file.basename
will return the base name (e.g. CoreFoundation) for the binary where the code from the current frame lives. That might be handier than having to check a particular function name.
Xcode doesn't support adding Python breakpoint commands to breakpoints yet, so you either have to set the breakpoint by hand (shown above) or look it up with "break list" and add the command to it after the fact.
One convenient trick to set up these sorts of things is to set a breakpoint in Xcode early on (e.g. main) and add the commands given above to that breakpoint and auto-continue.
Hope this helps,
Jim
>
> I know less about LLDB than you do, and as it’s not in a separate framework file I don’t think it can be done anyway.
>
> Cheers
> Dave
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden