I am debugging in issue in the Linux kernel using the crash utility to inspect a kernel crash core. But when I try to inspect contents of a particular instance of struct r5conf, crash tells me it does not know that struct or its layout.
crash> struct r5conf
struct: invalid data structure reference: r5conf
So, how do I tell crash about the layout of this structure?
Related
Process Explorer (aka procexp) require debug symbols to show kernel memory limits and a library that provide API for reading them. As I found, the symbols for currently running kernel (ntoskrln*) only are required, and the variables MmSizeOfPagedPoolInBytes and MmSizeOfNonPagedPoolInBytes are read from it. It is possible to acquire them from the kernel directly.
So why the debug symbols are required? Do they contain some information that impossible to get from the OS itself?
Because Process Explorer needs to know where in kernel memory those variables are located and it can different between each version of windows so symbols are the correct way to get this location. Microsoft publish public symbols.
not all kernel information is easily access from User space.
I'm currently working on an embedded CPU (ARM cortex-M0) on board. I'm experiencing crashes (HardFault) and thus, I'm trying to debug them.
Currently I can get a dump of the memory (I send everything in hex over the printf console, my only access to the memory).
My idea is to load that dump as coredump to gdb and thus being able to debug the program.
How is it possible to create a "real" coredump file from the raw memory dump, so that I can give it directly to gdb ?
I also tried to run my program in the gdb simulator to use the restore command with my raw memory but I don't understand how to run it. Do you have an idea ?
The main question here is in fact: How to create a coredump file that is compatible with gdb based on the program elf and the raw memory content ?
There are a pair of libraries that will do this: CrashCatcher and CrashDebug. This first prints a dump (which you are already doing but this prints in a specific format) and the second interfaces into gdb to allow loading the dump. For some reason CrashDebug doesn't create a core file but rather interfaces into gdb using gdb's target remote command. Same effect though. It supports Cortex-M0, M3, and M4.
People,
I have just working on OSX 10.9, and have a crash at hand to debug.
I see OSX has LLVM and LLDB which replaces well known and well documented gdb.
Anyway, I see in crashreport the precise stack trace, and that's pretty impressive from Apple.
However, I can get to image lookup in lldb and print the API name.
When I use verbose option with image lookup it prints few extra information, however, I am still not able to view local variables in the specific API.
I tried image dump, image sym-tab etc and other lldb options.
None of them seems to helping. Scanned through StackOverflow to see if its there's but not luck yet.
Therefore I have the Q
From OSX crashreports we cannot get stack-trace with local variables/arguments values?
How do we see a function arguments/locals variables using LLDB when we a OSX crashreport handy.
I see frame variable etc works fine when attaching to a running process, however these doesn't work when I crash the process and try to see the locals/arguments.
Request you to please guide.
THank you.
The CrashReporter output consists (mainly) of a backtrace of all the threads in the program, the list of libraries/frameworks that were loaded at the time (with their load addresses and Mach-O UUIDs to identify which build of each binary was being used) and the register context for the frame that crashed.
image lookup -va in lldb will show you where the arguments/variables were located at that given pc. If a variable is stored in register rbx at that point, image lookup will say it's in rbx. Often times a variable is stored on the stack and the location will say something like rbp-40 where rbp is the frame pointer register on x86_64. In that case, it means the variable is currently available on the stack at the value of rbp minus 40.
Crash reports do not include any of the stack contents -- they intentionally don't include things that might be sensitive. For instance, your program might have a password in plaintext in a stack local variable.
If a variable you're interested in is stored in a register at the point of the crash, you can use the register context section of the crash report to figure out what value was in there.
Often it's not quite that simple. If you can read your way through assembly language, the best way to figure out what really happened is to disassemble the crashed function and use the register context information to understand why the final instruction resulted in the crash.
Every now and then (ahem...) my code crashes on some system; quite often, my users send screenshots of Windows crash dialogs. For instance, I recently received this:
Unhandled win32 exception # 0x3a009598 in launcher2g.exe:
0xC00000005: Access violation writing location 0x00000000.
It's clear to me (due to the 0xc0000005 code as well as the written out error message) that I'm following a null pointer somewhere in my launcher2g.exe process. What's not clear to me is the significance of the '0x3a009598' number. Is this the code offset in the process' address space where the assembler instruction is stored which triggered the problem?
Under the assumption that 0x3a000000 is the position where the launcher2g.exe module was loaded into the process, I used the Visual Studio debugger to check the assembler code at 0x3a009598 but unfortunately that was just lots of 'int 3' instructions (this was a debug build, so there's lots of int 3 padding).
I always wondered how to make the most of these # 0x12345678 numbers - it would be great if somebody here could shed some light on it, or share some pointers to further explanations.
UPDATE: In case anybody finds this question in the future, here's a very interesting read I found which explains how to make sense of error messages as the one I quoted above: Finding crash information using the MAP file.
0x3a009598 would be the address of the x86 instruction that caused the crash.
The EXE typically gets loaded at its preferred load address - usually 0x04000000 iirc. So its probably bloody far away from 0x3a009598. Some DLL loaded by the process is probably located at this address.
Crash dumps are usually the most useful way to debug this kind of thing if you can get your users to generate and send them. You can load them with Visual Studio 2005 and up and get automatic symbol resolution of system dlls.
Next up, the .map files produced by your build process should help you determine the offending function - assuming you do manage to figure out which exe/dll module the crash was inside, and what its actual load address was.
On XP users can use DrWatsn32 to produce and send you crash dumps. On Vista and up, Windows Error Reporting writes the crash dumps to c:\users\\AppData\Local\Temp*.mdmp
I'm debugging an intermittent problem in which an application (created using C++ in Visual Studio 2005) is faulting. The event log provides the following information:
faulting module msvcr80.dll
version 8.0.50727.1433
fault address 0x00008aa0
I did a Google search and found many other examples of applications crashing with this particular fault address, but no indication of what it means.
Is there any way to find out what msvcr80.dll is doing at this address?
I tried attaching to a running instance of the application from Visual Studio to see what code is located at 0x00008aa0 -- but there doesn't seem to be anything there!
More generally, given an address somewhere in a Windows DLL, is there a way to figure out what the code is doing?
Windows will never map anything to addresses lower than 0x10000, so you are definitely AV'ing.
Googling myself, someone suggested using dependency walker to find out which module you're using that is directly dependent on msvcr80.dll -- since you are using VS 2005.
That might give you a clue where to start isolating the bug.
Address this low usually indicates a null pointer access violation. The offset of the member access accessed to the base pointer is 8aa0. Looks like a pretty large object. I would suggest you add null-asserts when you dereference pointers to objects of large data type.
You can try to use Microsoft debug symbols, in this case you will see normal function name instead of address.
In VS2005 you should do:
Go to Tools -> Options -> Debugging -> Symbols
Insert http://msdl.microsoft.com/download/symbols as a symbol location
Attach VS to your app instance and repeat the crash