I am investigating a faulty code. Application verifier shows heap is corrupted after below call:
AA!Class::Function+dbaf
I have map file with me.Please help me how to reach on line number using above information and information present into Map file.
Preferred load address is 00400000
0002:00000dc4 __imp_?Class#Function##QAEXV?$vector#Uty_point##V?$allocator#Uty_point###std###std##0PAV23##Z 0049bdc4
Note : I have anonymized class and function name.
Do you only have a map file? No PDB? If you have full symbols then use the map and .pdbs (and .exe) with WinDBG (are you on windows?).
I would imagine that you do seeing as how you have been given the name of the function.
IF not... dbaf is your answer. What does that equate to? The offset should be the location of faulty instructions.
Of course you would need to figure out the number of instructions (assembly instructions) that each has.
I remember being able to jump to the faulty code by having only the map file and the value of EIP (the instruction pointer, the address where the code crashed), a quick google search pointed me to this webpage: Map Files And DLL Rebasing. From what I remember in an ideal situation you can change the value of EIP directly in the Visual C++ debugger and it will jump to the corresponding code line.
Now, this was really a long time ago in the Visual C++ 6 era, I don't even know if it's still applicable today. As already pointed out you should really look into symbols and the program database options in Visual C++, there is tons of information about how to setup and use them.
MAP File Browser provides functions to allow you to turn crash addresses, or DLL offsets, or symbol offsets, or event log XML crash data into the corresponding symbol location.
Load the map file into MAP File Browser then go to the Query Menu.
Full disclosure: I wrote MAP File Browser.
Related
I have following scenario:
The main software I wrote uses a database created by a simulator. This database is around 10 GB big at the moment, so I want to keep only one copy of that data per system.
Assuming I have following projects:
Main Software using the data, located at /SimData
DLL using the data for debugging, searching for data at /SimData
Debugging tool to parse the image database, searching for the data at /SimData
Since I do not want to have all those programs have their own copy of SimData (not only to decrease place used, but also to ensure that all Simulation data used is always up to date for all programs).
I created for the DLL and Debugging Utility a link named SimData to MainSoftware/SimData, but when opening a file with "SimData\MyFile.data" it cannot find it, only the MainSoftware with the ACTUAL SimData folder can find it.
How can I use the MainSoftware/SimData folder without setting absolute paths?
This is on Windows 7 x64
I agree with Peter about adding the DB location as a configurable parameter. A common place to store that is in the registry.
however, If you want to create links that will be recognized by your software, try hardlinks. . fsutil should do the trick as described here.
You need a way to configure the database location. You could use an INI or other configuration file, or a registry setting, or a command-line input, or an environment variable. Or You could write your program to search a directory hierarchy... for example, if the various modules are usually siblings of each other in your directory tree, you could search for SimData/MyFile.data, ../SimData/MyFile.data, ../../MainSoftware/SimData/Myfile.data, and use the first one found.
Which answer is the "right one" depends on your situation.
I am trying to grab the addresses that associated with the start of the source code and the one at the end. I tried to do it using LLVM, Clang but I could not.
Is there a way to get the memory addresses that associated of each line in the source code?
Thanks
There are several possibilities:
You can use debug information for this. Note, however, that this
information might not be precise for optimized code
Alternatively,
you can use special linker script which will insert two symbols
before and after all the code in the code section.
I get crash reports from users with some Dr. Watson info, including the EIP. I want to start debugging, then set the EIP and see which line this takes me to. I also have Line Info enabled in the Release builds.
I have a label in source control so I can pull the sources I used to build it, but I have no idea if the linker will produce an EXE with the same offsets, otherwise the EIP would not be useful.
There is no garuntee that the offsets will be the same, unless you can ensure that all libraries used, all source, and the linker have not changed since you checked the code into version control. This is why many companies will actualy go to great lengths to keep the executables under configuration management.
From experience, if the offsets are not the same, then it becomes apparent very quickly so you can at least check, and if things are not making sense, ignore the EIP and other executable address offsets.
If you build a map file and saved that from the version that the crash report came from, and a map file from the rebuilt source, then you can do some comparative analysis (Function by function really) to get some usefullness back from executable addresses and offsets.
I'm making my application thread-safe. One of the steps is to synchronize access or eliminate usages of global variables. I'm using Visual Studio. I can't find any good way to find all global variables in my codebase. It's impossible to create a good text search pattern and I can't find any helpful tool. Do you guys know any good way to do that? It could be a source code analysis tool or a binary file analyzer.
This could help:
Open the project in visual studio.
Open 'Class View' of the project
Under the project title, you will find 'Global Functions and Variable'.
I have checked this with Visual Studio 2010 and above.
Edit: As suggested by Ajay in comments, you could also categorize items in groups. For grouping items:
In class view, right click on project title
Select `Group By Object/Member Type'
Select the required tree like variables or structures or enums etc.
One option might be letting the linker generate a map file (/MAP in Visual Studio).
You will get a .map file for each binary with two sections:
A table of segments
Start Length Name Class
0001:00000000 00010000H .textbss DATA
0002:00000000 000034b4H .text CODE
0003:00000000 00000104H .CRT$XCA DATA
0003:00000104 00000104H .CRT$XCAA DATA
0003:00000208 00000104H .CRT$XCZ DATA
0003:0000030c 00000104H .CRT$XIA DATA
...
A list of symbols (functions and data)
Address Publics by Value Rva+Base Lib:Object
0000:00000000 ___safe_se_handler_count 00000000 <absolute>
0000:00000000 ___safe_se_handler_table 00000000 <absolute>
0000:00000000 ___ImageBase 00400000 <linker-defined>
0001:00000000 __enc$textbss$begin 00401000 <linker-defined>
0001:00010000 __enc$textbss$end 00411000 <linker-defined>
0002:000003a0 _wmain 004113a0 f console4.obj
...
You can tell apart the functions from variables by the "CODE" / "DATA" designaiton in the segment list.
Advantage: You will get all symbols, even those in libraries, that were not removed by the Linker.
Disadvanatge: You will get all symbols, even those in libraries, that were not removed by the Linker. I don't know of any tool that does the code/data separation automatically.
I know the http://code.google.com/p/data-race-test/wiki/ThreadSanitizer program (product of google) which can work in Windows and on compiled code. It is dynamic instrumentation program (like valgrind or bit like qemu/virtualbox), which add some checks to memory accesses. It will try to find some threading problems. You can just run your program under control of threadsanitizer. There will be slowdown from dynamic translation and from instrumentation code (up to 20x-50x times slower). But Some problems will be detected automatically.
It also allows you to annotate some custom synchronization functions in source code.
Wiki of program has links to other thread-race detectors: http://code.google.com/p/data-race-test/wiki/RaceDetectionLinks
cppclean is a static analysis tool that can help you. From the documentation:
cppclean finds global/static data that are potential problems when using threads.
A simple example with a static local variable and a global variable follows.
./example.h:
void foo();
./example.cpp:
#include "example.h"
int globalVar = 42;
void foo(){
static int localStatic = 0;
localStatic++;
}
Open a terminal and run cppclean as follows:
$ cppclean --include-path . example.cpp
example.cpp:3: static data 'globalVar'
example.cpp:6: static data 'localStatic'
Unfortunately, cppclean has some parsing issues and bugs. However, these issues are pretty rare, and affected below a percent of all code I've tested.
You can try CppDepend by using its code query language
from f in Fields where f.IsGlobal select f
Maybe dumpbin tool will help here. You can run it with /SYMBOLS key to display the COFF symbol table and look for External symbols - global variables should be in this list. DUMPBIN /SYMBOLS.
You all are making this too complicated.
1.
Copy the code of each of your files (one at a time separate from the others) to a string or a wide string or etc. and then parse out everything that is from "{" to "}" uninclusive. Save the result to an exterior file. After the first time, then append to that file.
2.
Even if you have 1,000 lines total of what is left after all that parsing, in that are all of your globals (depending upon how you created the globals). If you created them via a namespace, etc. then go back and parse for that. I doubt that most programmers will have 1,000 globals, but for some applications it might be what they use. If you do not have too many at that point then manually edit that text file of the results.
I have found that maybe 90+ % of the answers on this site are bloated with far too much complexity that just eats up cpu time and memory space. Keep it simple.
You might find it handy to have a globals.h file which you load early and keep most or all of you globals there. It looks like time to do a lot of clean up.
One of my co-workers shipped a hot fix build to a customer, and subsequently deleted the pdb file. The build in question is crashing (intermittently) and we have a couple of crash dumps. We have all the source code in version control, and can compile it to an equivalent .exe and get symbols for that one. However, those symbols don't match the crash dump exactly. It seems like several of the functions are off by some constant offset, but we've only looked at a handful.
I'd love to be able to do the following (I can fake parts of this manually, but it's a huge amount of work): get a stack trace for each thread in the dump and cast pointers in the dump to the appropriate type and have them show up in the Visual Studio debugger. I'm using 2005, if that matters.
Is there a tool to let us recreate a pdb given the source code, all the .obj files, and the original .exe? Or is there a setting when we compile/link to say "make it exactly like this other exe you just did" or something like that?
Quick update, based on answers so far: I have the exe file that we sent to the customer, just not the pdb that corresponds to it, if that helps. I'd just as soon not send them a new build (if possible), because it takes about a week of running to get the crash dumps, and the customer is already at the "why isn't this already fixed?" stage. (If we do send another build, I'd prefer it to be one that either fixes the problem or has additional debugging in the area of interest, not just the same code.) I know it's possible to do some of this manually with a lot of guesswork; that's what we're currently doing. But it's a pain, so I'm hoping there's a way to automate it.
You cannot recreate a PDB to match a pre-existing executable. The PDB contains a "finger print" that is unique for each compilation. Unless you can make the old PDB magically reappear, you should whack your cow-orker in the back of the head (Gibbs-style, if you watch NCIS), recompile the whole thing, store the PDB somewhere safe, and ship a new executable to your customer, and let the crashes come.
If your build system enables you to recreate any binary from any revision you have in your history, then you should be able to get the build ID from the customer, and regenerate that same exact build ID, along with all the binaries and so forth. That will take a while if you have a large project, of course, but it will also yield the debugging file that you need.
If you have no way to perform an exact reproduction of a build, then look at this situation, think hard about some others that might crop up, and start moving to make it possible to regenerate all successful builds and associated files in the project's history. This will make it much easier to be able to work problems like this in the future.
When you have the sources, it's quite easy to find the correspondence between them and the exe file. Just ask them to send you the exe file along with the crash log and use IDA.
What you are asking is much more difficult than that, considering also that you need it for "one use only".