Re: Breakpoint problem
Re: Breakpoint problem
- Subject: Re: Breakpoint problem
- From: Jim Ingham <email@hidden>
- Date: Mon, 21 Mar 2011 11:29:44 -0700
This sounds like a bug in the debug information. If you set a breakpoint on line A in gdb, it actually will move the breakpoint forward to the first source line that has a "line table" entry in the debug information. So this sounds like for some reason there is no debug information for the catch block, and thus the breakpoint is getting moved to the line of code after the catch block, which is your "doSomethingMore()".
If you are using gcc-4.2 you might try clang, and if clang, gcc-4.2… You might also try putting a function call (e.g. a printf) into the catch block as that might force the compiler into thinking the catch clause is more "real"???
In either case, it would be good to file a bug report. If you don't mind giving us the .o file from a debug build, then great, otherwise, if you don't mind giving us the debug info for this file, do:
dwarfdump --debug-line --debug-info <YOUR_OBJECT_FILE.o> > /tmp/add-this-to-bug.txt
and then also include the source lines that the try/catch blocks are on so we can see what the line table is doing.
If you can make this happen in a simpler example even better.
Jim
On Mar 21, 2011, at 9:04 AM, Howard Moon wrote:
> Hi all,
>
> I'm trying to isolate where some code of mine is crashing, and am trying to use a try...catch(...) construct in C++ to do so, with a breakpoint on a line of code in the catch clause. This worked for a while last week, but as I've moved the try/catch deeper into my processing code, it has simply stopped working. The code now *always* breaks, on the next line following the catch clause's end brackets!
>
> I've done a complete clean, deleted the entire build directory, deleted the breakpoint, re-built, and set the breakpoint again, and it behaves exactly the same!
>
> The code is in an RTAS audio plug-in, and the code has been working for quite some time without problems, but we've found one special condition when processing audio that it can crash, and I'm trying to isolate how that one condition causes the crash. But I can't do it if I can't debug!
>
> My catch clause is like this:
>
> try
> {
> doSomething();
> }
> catch(...)
> {
> status = errOther; // breakpoint set here
> throw;
> }
> doSomethingMore(); // always stops here
>
>
> I've tried it with and without the throw in there (which I added to be sure it was actually catching an error, and not simply Xcode's debugger misleading me), but it's exactly the same. Whatever line of code immediately follows the ending curly bracket stops Xcode there, even though the breakpoint is set in the catch block above. I even tried setting the breakpoint on the {, and on the catch itself. Same result. And I can set two distinct breakpoints, one on the line shown above and one on the line that follows where it's hitting every time, and they show as two distinct breakpoints one different lines in the Breakpoints window, but either one being active causes Xcode to stop on that following line.
>
> It doesn't seem to matter WHERE I put this try/catch construct. No matter what code I wrap in it now (inside my very large processing function, anyway), it behaves exactly the same, always breaking on the following line and never in the catch block.
>
> Any ideas how can I get this working again?
>
> Thanks,
> Howard
>
>
> _______________________________________________
> 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