I am trying to debug a crash dump and I want to check the value of some variable on the stack. Problem is some methods have been inlined in the release build but I want to dump the variables (dv) of this.
If I go to the stack frame and do a dv command it shows me all variables for that particular function but not those within the inlined call.
I can do a uf (unassmeble function) command to see the assembly code but its a lot of work figuring things out.
It is not generally possible in an optimized build.
The optimizer might decide not to allocate memory to a variable, so studying the assembly code to figure out which register is the variable in is the only way.
Furthermore, if "Omit frame pointers" switch is on, the debugger wouldn't correctly show any variable allocated on stack.
You may try to add code to log variables you're interested in into a file.
You're going to have to figure this out through disassembly, unfortunately. If you're not already comfortable with this then it's as good a time as any to start practicing, it's a valuable skill to have for debugging tough problems.
Also, while it doesn't help you now, the PDB file format generated by Visual Studio 2012 now does a better job of tracking inline functions. Thus, in the future this particular situation should be mitigated in most cases. You can read more about the feature here:
http://dotnet.dzone.com/news/debugging-optimized-code
Related
First of all, thank you for taking the time to view my question and help. I noticed that a lot of questioners here show little or no appreciation, but I'm sincerely appreciative for the help and the community here :)
I wrote a C++ plugin (compromised of hundreds of source files) for an application I do not have the source code for (it's a video game). In other words, I only have the source code for my plugin, but not the game. Now, somewhere in those thousands of lines in my plugin, something causes the game engine to throw (probably an access violation) and I don't know where. By the time the debugger breaks, the stack is corrupted and all I get are hex addresses for DLLs I do not have the source for (but the exception occurs in my DLL for sure). I tried everything... I just can't seem to find where the exception occurs. Sometimes the debugger points to a "memory relocation" function (which I never used in my plugin), sometimes it points to the engine's GameFrame(), and other times it points to a damage callback (all these are just different member functions of a class).
I tried practically everything... I googled for hours trying to find out how to use other debuggers like WinDbg and Microsoft Application Verifier. I tried to comment out one or the other, or both, where the debugger points, but it still crashes. I even inserted OUTPUT("The name of the last executed function is: %s", __FUNCTION__) into EVERY function in my application hoping to painstakingly catch the last function but it seems any kind of I/O prevents the exception from occurring for some reason... And 10 minutes of debugging and the crash happens at some random last executed function.
I can't find out where this access violation is happening or where some temporary object is removed to cause these bad pointers (I check every pointer before using it), but damn, I'm reaching my limit's end here.
So, how does one debug the impossible... a random crash with a crappy debugger call stack? Thanks in advance for your patient and kind help!
My suggestion: try different debuggers (non MS), they catch different things.
My experience: a program I have source code and full debugging symbols corrupt the stack, VS nor WinDbg can help but Ollydbg comments a non-string var with the value "r for pattern.", so I had overwrote some string buffer onto this var. Also Ollydbg have option to walk the stack the hard way (not using dbghelp.dll)
From my experience, the old adage "Prevention is better than cure" is very relevant. It is best to prevent the bugs from creeping in, by following good software development practices (unit tests, regressions, code review, etc.) than to work it out later once the bugs show up.
Of course, real world is not perfect, and bugs do show up. To debug memory corruption, you have some nice tools like valgrind, which at least narrow down the problem sections for you to take a closer look at. Debugging a complex program is not easy, and if your debugger throws up, it requires a lot of persistence on your part. One technique I find useful is to selectively enable or disable certain modules, to narrow down the module has the problem.
Sometimes you need to use "referential transparency" to unload some modules. To give you a stripped down example, consider:
int foo = factorial(3);
If I suspect there's a problem in this code (and the debugger crashes before I can see the call stack), I have to try by removing this code, and see if the problem persists. However, foo may be used later, so I cannot just remove it. Instead I can replace it with int foo = 6; and continue.
Another important point is to always maintain a trace file, where your code keeps logging what it is doing. When a program crashes, the trace file can often help narrow down the problem. Of course, you disable the tracing by default, so that it doesn't cause a performance bottleneck.
Is it possible to 'peek' at the stack enough to deduce, perhaps by mapping an address to the debug .map file or something, what the calling function is programmatically?
I have a function that is called from a ton of different places, and basically if possible I would like to be able to programmatically log out who called the function so that I can trace the progression of parameter values over time, and be able to connect them back to where they may be going wrong. I could add a parameter so that the caller must provide a user string or something, but I'd like to do something less intrusive if it's possible.
GCC has features for this, such as __builtin_return_address (see http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html). They should be used only for debugging or special testing purposes and not as part of production code.
You can generate MiniDump files using windows API and load them later in the debugger and if symbols are available you should be able to debug the crash and investigate values of variables.
I want to print the code of a function in a DLL.
I loaded the dll, I have the name of the desired function, what's next?
Thank you!
Realistically, next is getting the code. What you have in the DLL is object code -- binary code in the form ready for the processor to execute, not ready to be printed.
You can disassemble what's in the DLL. If you're comfortable working with assembly language, that may be useful, but it's definitely not the original source code (nor probably anything very close to it either). If you want to disassemble it, loading it in your program isn't (usually) a very good starting point. Try opening a VS command line and using dumpbin /disasm yourfile.dll. Be prepared for a lot of output unless the DLL in question is really tiny.
Your only option to retrieve hints about the actual implemented functionality of said function inside the DLL is to reverse engineer whatever the binary representation of assembly happens to be. What this means is that you pretty much have to use a disassembler(IDA Pro, or debugger, e.g. OllyDbg) to translate the opcodes to actual assembly mnemonics and then just work your way through it and try to understand the details of how it functions.
Note, that since it is compiled from C/C++ there is lots and lots of data lost in the process due to optimization and the nature of the process; the resulting assembly can(and probably will) seem cryptic and senseless, but it still does it's job the exact same way as the programmer programmed it in higher level language. It won't be easy. It will take time. You will need luck and nerves. But it IS doable. :)
Nothing. A DLL is compiled binary code; you can't get the source just by downloading it and knowing the name of the function.
If this was a .NET assembly, you might be able to get the source using reflection. However, you mentioned C++, so this is doubtful.
Check out this http://www.cprogramming.com/challenges/solutions/self_print.html and this Program that prints its own code? and this http://en.wikipedia.org/wiki/Quine_%28computing%29
I am not sure if it will do what you want, but i guess it may help you.
Looking for a quick and dirty way to identify the caller of a constructor (or any function for that matter) I am writing macros to help identify memory leaks by dumping the this pointers to OutputDebugString.
Knowing where ctor and dtor was called from would help identify the problem.
tnx
\0
If you're using visual studio you can attach the debugger and rather than having a break-point have a trace-point. You do this by right clicking the break-point and choosing When Hit.... Then select to print a message including the stack trace. This message will be sent to the output pane and you can analyze all calls at your leisure.
The best way I can think of is to run your program in a debugger and put a breakpoint in the constructor. Next, examine the call stack.
If you want to target one specific allocation in one specific class, you can keep an allocation count and see which allocation number doesn't get freed. Run the program again, and break on the right allocation number.
If you need to have the call stack dumped to a log, I know it is possible to generate a stack dump using for example win32 API. A more general approach would be to keep an explicit call stack as a global/thread specific state, for example in an std::vector<std::string>-object. (Use RAII to ensure that every push_back is accompanied by a pop_back)
It seems to be you are on windows (OutputDebugString). So you can use the StackWalk64 api to get the stacktrace.
See the "Printing the stack trace in C++ (MSVC)" question for more details.
There is also a lot of leak detection tool available (BoundsChecker, etc).
There is no quick and dirty way for this, C++ does not offer any portable way of looking into a stack-trace. If you want to search for memory-leaks, I'd recommend looking into valgrind and similar tools, they do a great job. As coding guideline, avoid memory-leaks in the first place by using RAII (always have an owner for a resource).
Using gcc? Why not generate a stack trace?
If you're using Linux then Valgrind does everything you want and more. I find it indispensable when developing in C++.
If you're using g++, you can build your project for coverage. When you run over some sample code, you can then view the coverage of your program using gcov.
This output includes the call tree, and you should be able to see calls to constructors, and the functions that are calling them.
The only downside I can think of is that you will only get output for code that is actually executed, and so you'll need to have good test cases. That being said, performing coverage analysis is well worth it anyway. Finally, I highly recommend that you use lcov to view the results!
Can you manipulate the ctor and dtor? I'm no C++ developer and you should easily see this, but perhaps in this case you could pass i.e. a reference on the caller to the constructor.
You running under Windows? Visual Leak Detector has helped me in the past find memory leaks.
Using RAII helps reduce memory leaks too.
If you are feeling adventurous then you can overload the new and delete functions. Paul Nettle does this in his MMGR.
The advise to use a debugger and the call stack is sound and probably the best solution possible. However if you are without a debugger it will not be much help.
Do you know the calling convention being used for your constructor? If so you can use some inline assembler (provided your compiler supports it) to examine the order of function calls. With std calling, the most common convention for Win32, popping the stack will reveal the pointer to the address to return to after the function has been called (i.e. some place in the calling function). This isn't ideal, but you can then go backwards from that point until you reach an address you know to be the start of a function. The only problem here is that you need to get the addresses for all of your functions to be able to do this... this can be done using a simple trick to get the value of eip into another register right at the top of the function, then moving this value into an array to be checked against later when debugging, something like (intel syntax):
call label
label:
pop eax
mov [address of next array entry], eax
Basically you don't, instead of you save all allocation/deallocation and discover who don´t free objects/areas.
See this answers
Heap corruption under Win32; how to locate?
Good lock.
Thanks everyone for the feedback. putting a break point in the ctor is not an option due to hundreds of calls for new objects in even a short lifecycle of the program.
Tracing macros in the ctor and dtor did the trick.
Visual Leak Detector and Stackwalk64 look very promising
also found AfxDumpStack(AFX_STACK_DUMP_TARGET_ODS); // OutputDebugString
but it is VERY noisy
I have the following:
classA::FuncA()
{
... code
FuncB();
... code
}
classA::FuncB(const char *pText)
{
SelectObject(m_hDC, GetStockObject ( SYSTEM_FONT));
wglUseFontBitmaps(m_hDC, 0, 255, 1000);
glListBase(1000);
glCallLists(static_cast<GLsizei>(strlen(pText)), GL_UNSIGNED_BYTE, pText);
}
I can hit breakpoints anywhere in FuncA. If I try to step into FuncB, it steps over. It will accept a breakpoint in FuncB, but never hits it. I know it is executing FuncB, because I can put a MessagBox() call in FuncB and get the message box.
I'm new to VS2005 after a few years away from extensive VC6 usage. The one situation like this I recall from my VC6 days, is if symbol information is not available. However, in this case both functions are in the same file, so the symbol information must be correct. Also in that case I think you couldn't even set the breakpoint.
I've tried all the silly voodoo like rebuilding the whole solution.
What stupid thing am I overlooking?
EDIT: Added code for FuncB in response to comment about it possibly being essentially inline-able. (It's just the exact sample code from MSDN for wglUseFontBitmaps [minus comments here]). I don't see how inlining that would impede stepping through each call.
Make sure all compiler optimizations are disabled (/Od). Compiler optimization can cause problems with debugger breakpoints.
Not sure what the problem is, but one thing you might try is to look at the disassembled code. You can switch betwen the source code and disassbled view with VS. I do not have the IDE in front of me at work, so the terms might be slightly off.
If you put the debugger into this mode, you can see what the assembly instructions that are executing. This helps sometimes to determine these kinds of problems. Sometimes, although not usually with a debug build, calls are optimized out by the compiler.
If everything fails try updating to VS2005 SP1 if you don't already have it...
Sounds strange indeed!
Thanks for posting the code. This is clearly not what I had guessed.
For posterity's sake, and to clear things up, my guess was that if (1) the function was one line and (2) the compiler inlined the function, then (3) the debugger might not know how to step into it. This guess relies on the fact that some debuggers do have trouble with inlined code and other compiler optimizations. I'm not familiar enough with Visual Studio's debugger to say whether it is on that list.
On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. ...
GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
The GCC manual used to have a statement that some compilers would refuse to emit debugging symbols in optimized code because their debuggers couldn't follow it.
actually i had a similar problem, found out the code wasnt getting compiled when i was running the program, so make sure you 'compile' the program before you try running it