Here's some code I have:
MyClass* MyClass::getInstance()
{
static MyClass instance;
return &instance;
}
I want to look into this singleton's current values. But I'm currently paused three hours into execution, and the reason I'm paused is that I'm out of memory. So I can't put a breakpoint in this method there to see what the value is.
My question then is how to refer to this instance
variable from a global scope. I've tried referring to it as MyClass::getInstance::instance
but that doesn't work. I'm guessing getInstance
has to be decorated somehow. Anyone know how?
This is in Visual Studio 2008.
That code just looks dangerous... :-)
But anyway, your mangled name is going to depend on your Calling Convention So before you find your mangle name you need to know what your build environment is using as the calling convention. MSDN has a lot more information on calling convention.
Besides this, one way to find out all this information about your class is to inspect your VTable, which is found in the first 4 bytes of your object. A nifty trick that reversers use is a hidden VC++ Flag reportSingleClassLayout that prints the class structure in an ASCII art manner.
In gdb, you can put a watchpoint on the mangled name of the variable.
For example, with this function:
I can watch _ZZ1fvE3xyz (as mangled by gcc 3.2.3 or gcc 4.0.1).
Well, the function-scoped static
instance
variable doesn't show up in a.map
file generated bycl.exe /Fm
, and it doesn't show up when I usex programname!*MyClass*
in WinDbg, so the mangled name doesn't seem to containMyClass
at all.Option 1: Disassemble
MyClass::getInstance
This approach seems easier:
From this we can tell that the compiler called the object
$S1
. Of course, this name will depend on how many function-scoped static variables your program has.Option 2: Search memory for the object
To expand on @gbjbaanb's suggestion, if
MyClass
has virtual functions, you might be able to find its location the hard way:x
command to find the address of MyClass's vtable:s
command to search the process's virtual address space (in this example, 0-2GB) for pointers to MyClass's vtable:dt
command to find the class's vtable offset, and subtract that from the addresses returned from the search. These are possible addresses for the object.dt programname!MyClass 0042b360
to examine the object's member variables, testing the hypothesis that the object is located at 0042b360 (or some other address). You will probably get some false positives, as I did above, but by inspecting the member variables you may be able to figure out which one is your singleton.This is a general technique for finding C++ objects, and is kind of overkill when you could just disassemble
MyClass::getInstance
.