Re: Debugger halting in wrong place
Re: Debugger halting in wrong place
- Subject: Re: Debugger halting in wrong place
- From: Rick Mann <email@hidden>
- Date: Thu, 05 Apr 2012 14:37:17 -0700
Thanks guys. I discovered that shortly after I sent the email. I would've solved my crash in minutes had I realized frames were being hidden. I'm not really sure it's all that beneficial to hide stack frames, and it sure can screw one to hide them by default.
I'm so used to GDB giving me crappy stacks in the past that if a stack looks useless, I just assume it's useless, and that I have to debug by trial and error.
I vaguely recall getting bitten by this before. Hopefully this time I will have learned my lesson.
--
Rick
On Apr 5, 2012, at 12:31 , Jens Alfke wrote:
>
> On Apr 5, 2012, at 12:05 PM, Rick Mann wrote:
>
>> The debugger stops on the setter, shows EXC_BAD_ACCESS, and has two more frames in the stack (it's stopped on frame 9 here). I didn't realize I wasn't showing the entire stack, and puzzled over this for hours. Frames 7 - 1 were hidden.
>
> The debugger selects the topmost frame that it has source code for, so that it'll be showing you source code instead of assembly. That behavior I think makes sense to everyone.
>
> The problematic behavior is the way it hides stack frames that don't have source, unless you move that slider at the bottom of the debug navigator all the way to the right. This can be useful, but it confuses a _lot_ of people. You're far from the first to bring it up on this list or on cocoa-dev. My opinion is that this feature should be off by default, i.e. the slider should be all the way to the right.
>
> —Jens
On Apr 5, 2012, at 12:32 , Fritz Anderson wrote:
> On 5 Apr 2012, at 2:05 PM, Rick Mann wrote:
>
>> I've chased down a crashing bug and determined that the debugger (both GDB and LLDB) are showing the crash in the wrong place. I wonder if they can be improved to be more accurate.
>>
>> In this case, I'm setting a dynamic property on an NSManagedObject subclass. A view class is using KVO to observe that property, but is getting dealloced beforehand.
>>
>> The debugger stops on the setter, shows EXC_BAD_ACCESS, and has two more frames in the stack (it's stopped on frame 9 here). I didn't realize I wasn't showing the entire stack, and puzzled over this for hours. Frames 7 - 1 were hidden.
>>
>> Had the debugger stopped on frame #2 and showed those neighboring frames, it would've been immediately obvious what was going on.
>
> I assume you're already aware of the slider at the bottom of the Debug navigator, which filters the stack trace?
>
> When it's all the way to the left, the whole trace is shown. Somewhere toward the middle, it shows only the frames immediately surrounding your code and the site of the crash, on the theory that you don't usually care about how execution was crawling around in code you can't fix. All the way to the right, it filters almost everything, which is useless.
>
> — F
>
_______________________________________________
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