I have to analyze a coredump.
Most data of my process is contained in a mapped file.
When I want to access to that data, gdb says that it cannot access that data because it hasn't mapped the file.
Do you know how to make gdb map that file in order to have access to data.
how to make gdb map that file in order to have access to data.
I don't believe GDB has any commands to do that.
What you could do is wrap the data file into an object file, and use add-symbol-file foo.o <suitable-load-address>. You could use objcopy --add-section to do this. Example.
On Linux, you could also configure core dump to include read-only mappings (normally such mappings are excluded to make the core smaller), which would make any special steps unnecessary. See man 5 core, the section on Controlling which mappings are written to the core dump.
Related
I have a core dump from a user. The main program loads selected plugins via dlopen. The process aborted in the plugin module. The user provided a backtrace that includes the filename of the plugin, and the function it aborted in.
I need to look at data, such as arguments passed to the function. How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?
How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?
GDB should do that automatically (the load addresses are contained inside the core).
All you need to do is supply the binaries that match customer's environment exactly. See also this answer.
If the core file is good then it should contain the call stack for the crash. You indicated that the crash occurred in the plugin module and function. By going 'up' the stack, you should be able to see the crash point and the containing function. In general, you should be able to look at the local variables including arguments to the function/method.
In short, just debug it like any other core file. Once the call to dlopen completes successfully, the shared library looks (nearly) the same as others loaded at start up.
If you share the bt, I can give some more definitive pointers.
As Employed Russian noted, you local executable and shared libraries must be bitwise the same as your clients. If the local version is different, it will throw off the mapping that gdb does between the core and the executable. This usually results rubbish but sometimes results in a stack that appears vaguely correct. As a result the programmer spends time chasing false leads. This situation is really aggravating!
I think this question hasn't been answered for my use-case.
We wish to detect if the user has changed a file without re-reading its contents for the purposes of caching a computation result based on the file contents. Our program is a long-running one that lets the user click a button to perform a computation based on data entered in the program and data stored in external files (sorry, I can't be more specific than that). The external data needs to be read, processed and various data structures need to be built based on it, so we try to cache those between computations to speed up re-computes when the user changes the data in the program itself, but not the data in the external files. However, if the external file has changed, we have to re-read that.
For each external resource we're checking if the modification time and file size have changed, but that's not really all that robust and can lead to user frustration if they have e.g. fileA and fileB with the same size and timestamp and copy or fileA to fileC, use fileC as an external resource, and then copy fileB to fileC. The system preserves the modification time of the original file and the sizes are the same, so we don't re-read the external resource.
Our program runs on Windows, macOS and Linux, is written in C++ and we're perfectly OK with using platform-specific code to detect file changes. We're interested in the most robust way to detect if the contents of a file identified by a file path have changed without actually reading the file itself.
I've made this answer a community wiki so others can add their ideas for the various platforms listed in the question.
Linux
MacOS
Windows
Option 1
Set up a thread that watches the directory containing the file. When the directory changes, you'll have to check if the file you care about has actually changed. That may mean opening and re-reading the file, (e.g., to compute the current checksum). But since you have to do this only after a change notification, this overhead may be acceptable.
I believe (but have not verified) that if someone copies a same-size, same-timestamp file over an existing file, you'll get a directory change notification.
Option 2
Hold the file open with an opportunistic lock. This involves creating the lock with a call to DeviceIoControl and then issuing a blocking call to GetOverlappedResult, which will unblock when another process attempts to change the file. Your program can the release the lock, allowing the other process to update the file, and know that the file is being changed.
Is there any api's which load a crash dump, symbols from the symbol store and then allow programmatic access to the information?
I want to create a tool to auto process crash dumps and produce a report based on them.
Use a command file for Windbg which sets up your configs and then runs !analyze. Set windbg to output to a file (as described here: windbg: Command output to text file)
Then you can enjoy trying to sort, categorize, etc. the output from that. !analyzewill do a decent job of analyzing most crashes. If it can't, I doubt you'd be doing a better job with your own code, unless you have a lot of experience in analyzing crash logs by program (I haven't ever tried, although I have a decent idea of what to look for, I wouldn't necessarily want to write code to actually do it - I have written code to write logs when the system has crashed, so I know what you usually need).
The Windows dbghelp API loads symbols and line number information to support making stack back traces. Do not know API for reading crash dump files.
Debug diagnostic tool has a com interface that can load a dump, process it using symbols and give you the information back.
http://www.microsoft.com/en-au/download/details.aspx?id=26798
Tutorial: http://codenasarre.wordpress.com/2011/06/14/how-to-control-a-debugger-engine/
Given an address I want to find at runtime without access the PE header on disk if it belongs to the .text section (Is there any other executable section?).
More details:
The address is in the same process that I'm running but it can be form a different dll static library or the executable that runs the process.
I'm running on windows using VS2010 Win32.
You want VirtualQuery. It fills in a MEMORY_BASIC_INFORMATION structure. If mbi.Type == MEM_IMAGE, you're looking at a mapped image. You probably also want to look at the AllocationProtect to check for PAGE_EXECUTE or one of its variants (otherwise you could be looking at something like read-only data mapped from the executable, such as a bitmap resource or something on that order).
Consider DbgHelp API: http://msdn.microsoft.com/en-us/library/ms679292(v=vs.85)
For example,
EnumerateLoadedModulesEx gives you information on loaded modules with base addresses and sizes
(so you can id the module)
MapDebugInformation retrieves information about module's sections
Is it possible to modify an executable file on runtime (I'm asking about Windows XP/Vista/7/Server)? I've just evaluated SmartUtils Portable Storage application. It can create so called "managed executable storage files" that modify them-self at runtime... Such storage file is like standard self-extracting archive (the data is apended to an executable module) but the main difference it that you are able to view and modify its content without the main program. How is it possible? I need similar functionality in my project (C++): I want to be able to create executable that can modify data attached to it.
If all you're really asking is how SmartUtils Portable Storage does it's magic, then I would suggest that it is a self-executing zip archive. The EXE of the archive (just as WinZip or 7-Zip create) auto-extracts and executes your application exe from a temp folder, and gives you an API that boils down to ways to extract, manipulate, and then modify that original self-executing archive.
So Windows is never trying to modify a running .exe. Rather, your .exe (temp file extracted & run) is what is executing (and the libraries bound to it), which manipulates the source .exe (really a self-executing archive - possibly .zip).
The next time the user "runs" the modified "exe", again your .exe is extracted & run, and it can again manipulate the self-extracting .exe.
I hope that makes sense to you.
And this is just a best guess!
Yes - a common technique is to append data files at the end of an executable.
Typical scheme is to write a 0x00000000 integer to the end of the executable and then append each file followed by it's size in bytes.
Then when the executable needs to read the data it checks the last 4bytes in it's own file, uses that as the file length and copies that number of bytes form it's own file, it then checks the next 4 bytes as another length and copies that as a file , until it gets a length of 0000. If you also need to code the file names - that adds a little complexity but it's basically the same idea.
You can append a TOC pointer to an EXE (and probably a magic ID cookie) so you can verify that it is a TOC pointer, and then use that to back up to the start of each appended record.
As long as you don't mess up the file's header & main contents, it should still be loadable by the OS.
However, you sacrifice any signing your EXE had - and you probably have various permissions issues to contend with...
I have written tools for my development environment that opens a Windows EXE, extrapolates the resources in it, modifies various ones, and repackages the whole thing. We use this to mark a beta as release (so it modifies the version records).
You can do anything you want to an EXE file if you know the structure of it and rebuild it correctly.
Since this is tagged as Windows, you might also consider "Alternate Data Streams". That allows you to treat a single file almost as a directory. You can add a stream called Program.EXE:ExtraData to your program and write to that with the normal file functions.
Then again, your executable most likely will be in Program Files\, which isn't writeable for normal (non-elevated) users.