Let's say I have four different dump files. When I open them in a debugger, I get the assembly lines that the program broke into. Two dumps are showing the same assembly lines, the other two are showing different assembly lines.
Does that mean that the first two crashes occurred because of the same line in the code, same exception, in the same call stack?
Please note that I already checked the "Match source with disassembled code" question, but I can only work with the dump file. No source code, no symbols, Windows only.
Related
I keep getting this message Rect: identifier "posPt" is undefined hundreds of times in my debug output, yet, I can't find it in the code I'm debugging. So I tried to break whenever one of the following functions are called: _CrtDbgReport, _CrtDbgReportV, _CrtDbgReportW, and _CrtDbgReportWV, which I found by drilling down through the TRACE code. I also found _CrtDbgReportT and _CrtDbgReportTV as well, but they don't seem to have any linkage as I couldn't set a breakpoint on them.
In any case, it still wouldn't break, so either these are not being called and some other similar function is, or the debugger isn't getting all instances of the linkages.
So, my question is how do I find out where the output is being generated?
EDIT: The application is C++ native code with several DLLs linked in.
This was a while ago, and I do not know if I ever found the issue. However, looking back at this, it may have been caused by a breakpoint that had an Action to log to the output window, either referencing a variable that doesn't exist anymore, or the breakpoint being moved due to lines being added/removed by a source control programme, moving the variable out of scope.
Given the output Rect: identifier "posPt" is undefined, the action would have read as Rect: {posPt}.
I am trying to learn fortran. I wanted to replicate a certain step in a paper but I ran into trouble.
I compiled the file AERsimulation.f95 (I turned on all debugging functions in gfortran I am aware of) I could generate an .out file without any errors (a lot of warnings, however...)
When I tried to run the .out file I got the error message
Fortran runtime error: Index '0' of dimension 1 of array 'k' below lower bound of 1
Now, it is quite difficult for me to understand why exactly this happens. I guess, my question is, whether there is a better way of debugging, so that I can see and click through the code 'live' and see why the error occurs. (I am thinking of the matlab-debugger for instance...)
Any suggestion/hint is very welcome
The files I use are
AERsimulation.f95
AERDATANB.TXT
Thank you very much
Best
Derrick
The meaning of your error message is that you try to access an array element at the position 0 of the array. Arrays in Fortran start at 1 by default.
If you are looking for a better way to debug, try gdb (command line) or if you prefer a graphical interface you can try the Netbeans IDE. It has (limited) support for Fortran an a debugging mode where you can click line by line through the code and see the values of all variables and so on.
On command line try:
gdb name_of_executable
run
the debugger will stop at the line which causes the error.
I'm trying to generate a PE format executable; I'm at the stage where I have something that dumpbin is happy with, and as far as I can tell is not materially different from an empty program linked with Microsoft's linker, but Windows still rejects it: PE file - what's missing?
If I had some algorithm for generating a valid PE file, maybe I could hill climb from there. Here's what I've found so far:
There's plenty of documentation, sample code and tools for reading PE files, as opposed to generating them from scratch.
PE Bliss lists generation among its features, but won't compile.
Sample assembly language templates for PE file generation concentrate on minimizing size. The most promising looking one generates a file that Windows rejects even though as far as I can see it should be accepted; the one I found that did work, ironically, generates a file that Windows accepts even though as far as I can see it should be rejected, since almost every nominally essential component is missing or malformed.
Is there any sample code available that generates a correct PE file?
Here's the classic page about generating PE from scratch:
http://www.phreedom.org/research/tinype
As for the generic list of required/optional parts, see corkami page on the PE format:
http://code.google.com/p/corkami/wiki/PE
See also the code tree for many examples of small PE files, generated completely from scratch.
In Visual Studio, is it possible to edit assembly language code while stepping through each statement (so that statements in the program can be modified while the program is running?) It would be useful to modify statements in a program while the program is running (for debugging purposes), but I'm not sure if this is possible yet.
You can modify the source code, but it doesn't get reassembled to produce a new binary during your debugging session. The debugger will tell you the "source no longer matches the code" but you can still step. Your display may be confusing because, well, the source code no longer matches the object code :-} I often add comments to instructions or in blank lines, which gets me the complaint, but you can still single-step and see the right source lines in this special case.
I think you can manually modify the memory containing the instruction you want to patch. I've not ever bothered to do this; its easier to set a breakpoint where I'm at, re-assemble, and then run till the breakpoint.
You can modify all the registers and data memory pretty easily (actually you have to use this to modify the code memory, I think!).
A really useful thing to do is "Set Next Statement" to set the PC back to a somewhat earlier place in the code; you can often then step forward to point of failure, if the registers and memory aren't changed. (put cursor in your source or disassembly window, click on a line, then right-click "Set Next Statement")
Is it possible for the debugger (or the CLR exception handler) to show the line where the exception happened in Release mode using the pdb?
The code, in release mode, is optimized and do not always follow the order and logic of the "original" code.
It's also surprising that the debugger can navigate through my code step by step, even in Release mode. The optimization should make the navigation very inconfortable.
Could you please clarify those two points for me?
I'm not as familiar with how this is done with CLR, but it's probably very similar to how it's done with native code. When the compiler generates machine instructions, it adds entries to the pdb that basically say "the instruction at the current address, X, came from line 25 in foo.cpp".
The debugger knows what program address is currently executing. So it looks up some address, X, in the pdb and sees that it came from line 25 in foo.cpp. Using this, it's able to "step" through your source code.
This process is the same regardless of Debug or Release mode (provided that a pdb is generated at all in Release mode). You are right, however, that often in release mode due to optimizations the debugger won't step "linearly" through the code. It might jump around to different lines unexpectedly. This is due to the optimizer changing the order of instructions, but it doesn't change the address-to-source-line mapping, so the debugger is still able to follow it.
[#Not Sure] has it almost right. The compiler makes a best effort at identifying an appropriate line number that closely matches the current machine code instruction.
The PDB and the debugger don't know anything about optimizations; the PDB file essentially maps address locations in the machine code to source code line numbers. In optimized code, it's not always possible to match exactly an assembly instruction to a specific line of source code, so the compiler will write to the PDB the closest thing it has at hand. This might be "the source code line before", or "the source code line of the enclosing context (loop, etc)" or something else.
Regardless, the debugger essentially finds the entry in the PDB map closest (as in "before or equal") to the current IP (Instruction Pointer) and highlights that line.
Sometimes the match is not very good, and that's when you see the highlighted area jumping all over the place.
The debugger makes a best-effort guess at where the problem occurred. It is not guaranteed to be 100% accurate, and with fully optimized code, it often will be inaccurate - I've found the inaccuracies ranging anywhere from a few lines off to having an entirely wrong call stack.
How accurate the debugger is with optimized code really depends on the code itself and which optimizations you're making.
Reference the following SO question:
Display lines number in stack trace for .NET assembly in release mode