Re: Workaround for breaking in C++ constructors and destructors? Grrrrr!
Re: Workaround for breaking in C++ constructors and destructors? Grrrrr!
- Subject: Re: Workaround for breaking in C++ constructors and destructors? Grrrrr!
- From: Jim Ingham <email@hidden>
- Date: Thu, 2 Mar 2006 09:00:57 -0800
The problem is that there are multiple copies of each ctor/dtor, and
the behavior of gdb's "break" command is to break in the first
instance it finds of the expression you gave it. There's another gdb
command - rbreak - which breaks on all the symbols that match the
expression you give it (this is a regular expression match, though
that's not important to this example.)
So you can use rbreak to put breakpoints on all the ctor/dtor
instances, for instance:
(gdb) break C::~C()
Breakpoint 1 at 0x29e0: file destructor.cpp, line 7.
(gdb) run
Starting program: destructor
Reading symbols for shared libraries . done
in destructor
Program exited normally.
<<< Oops, that didn't work...
(gdb) rbreak C::~C()
Note: breakpoint 1 also set at pc 0x29e0.
Breakpoint 2 at 0x29e0: file destructor.cpp, line 7.
void C::~C();
Breakpoint 3 at 0x2a20: file destructor.cpp, line 7.
void C::~C();
(gdb) run
Starting program: /Volumes/ThePlayground/Users/jingham/Desktop/
destructor
going
Breakpoint 3, C::~C (this=0xbffff218) at destructor.cpp:7
7 printf("in destructor\n");
There's no "future" equivalent of rbreak, however. So if you want to
break in a ctor/dtor that's in a loaded bundle or something like
that, you'll have to wait till the library is loaded, and then set
the breakpoint with rbreak. There's also no file:line equivalent of
rbreak, so you can't say:
(gdb) rbreak destructor.cpp:7
or rather you can issue this command but it won't set any
breakpoints. rbreak only matches symbols, not line specifications...
Jim
On Mar 2, 2006, at 8:23 AM, Sean McBride wrote:
Hi all,
It seems to be a well known problem that gdb cannot reliably break in
ctors and dtors, and that the bug has been around for years. I'm sure
it will be with us for years to come. :(
So I'm looking for a workaround... any suggestions? Is there a way,
with the command line, to make gdb break on all versions of a ctor/
dtor?
Right now my workaround is to sprinkle Debugger() calls where I need
them, but that's a huge PITA. Also Xcode generally crashes
stepping out
from __pthread_kill().
Thread 0 Crashed:
0 <<00000000>> 0xfffeff18 objc_msgSend_rtp + 24
1 com.apple.CoreFoundation 0x9073f5c0
_CFArrayReplaceValues + 372
2 com.apple.CoreFoundation 0x9073f438 CFArrayAppendValue +
200
3 ...ple.Xcode.DevToolsInterface 0x98f87734 -
[PBXDebugDataValueViewModule setContainerDV:] + 292
4 ...ple.Xcode.DevToolsInterface 0x98f8c808 -
[PBXDebugStackFrameViewModule updateUI] + 568
5 ...ple.Xcode.DevToolsInterface 0x98f874b8 -
[PBXDebugDataValueViewModule setModel:] + 64
6 ...ple.Xcode.DevToolsInterface 0x98f8ba74 -
[PBXDebugStackFrameViewModule setModel:] + 116
7 com.apple.Foundation 0x928ee808 -[NSArray
makeObjectsPerformSelector:withObject:] + 264
8 ...ple.Xcode.DevToolsInterface 0x98f8d310 -[PBXLSModel
dealloc] + 40
9 ...ple.Xcode.DevToolsInterface 0x98f8ce80 -[PBXLSDataValue
dealloc] + 416
10 ....Xcode.GDBMIDebuggingPlugin 0x014bcef0 dyld_stub_vm_protect
+ 21522000
So I am absolutely stuck for some way to debug within my dtors!
Thanks,
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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