Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

I am interested in being able to load a core file on linux machines and save out a windows minidump file with enough info for backtraces and maybe some variables. I know we can ingest minidump files in LLDB, but can we produce them? I was planning on writing a python module that adds a new save_minidump command, but wanted to check if anyone has anything like this already.

Also any URLs for the minidump file format would be appreciated.

Greg Clayton

We can’t produce them, but you should check out the source code of google breakpad / crashpad which can.

That said it’s a pretty simple format, there may be enough in our consumer code that should allow you to produce them

Zach’s right. On Windows, lldb can produce a minidump, but it just calls out to a Microsoft library to do so. We don’t have any platform-agnostic code for producing a minidump.

I’ve also pinged another Googler who I know might be interested in converting between minidumps and core files (the opposite direction) to see if he has any additional info. I don’t think he’s on lldb-dev, though, so I’ll act as a relay if necessary.

The minidump format is more or less documented in MSDN.

That being said, it’s not exactly trivial to produce a good minidump. Crashpad has a native & cross-platform minidump writer, that’s what I’d start with.

That being said, it’s not exactly trivial to produce a good minidump. Crashpad has a native & cross-platform minidump writer, that’s what I’d start with.

Addendum: I realized after sending the email that if the goal is to convert core files → LLDB → minidump a lot of the complexity found in Crashpad can be avoided, so perhaps writing an LLDB minidump writer from scratch would not be too bad.

Also, if the goal is to have this upstream somewhere, it would be nice to have a tool this be a standalone tool. This seems like something that you shouldn’t be required to start up a debugger to do, and probably doesn’t have many (or any for that matters) on the rest of LLDB.

The goal is to take a live process (regular process just stopped, or a core file) and run “save_minidump …” as a command and export a minidump file that can be sent elsewhere. Unix core files are too large to always send and they are less useful if they are not examined in the machine that they were produced on. So LLDB gives us the connection to the live process, and we can then create a minidump file. I am going to create a python module that can do this for us.

Greg

What about the case where you already have a Unix core file and you aren’t in a debugger but just want to convert it? It seems like we could have a standalone utility that did that (one could imagine doing the reverse too). I’m wondering if it wouldn’t be possible to do this as a library or something that didn’t have any dependencies on LLDB, that way a standalone tool could link against this library, and so could LLDB. I think this would improve its usefulness quite a bit.

Also one could imagine using it for many other things too. For example, given a windows dump file, strip it down (i.e. remove heap, etc), or similar types of options for operating on Unix core files to remove certain types of info etc

fwiw I had to prototype a new LC_NOTE load command a year ago in Mach-O core files, to specify where the kernel binary was located. I wrote a utility to add the data to an existing corefile - both load command and payload - and it was only about five hundred lines of C++. I didn't link against anything but libc, it's such a simple task I didn't sweat trying to find an object-file-reader/writer library. ELF may be more complicated though.

Yea, I think something like this would actually make a useful llvm utility. Call it llvm-core or something, and it links against the library LLVMCoreFile. We could move all the code for consuming and producing Windows minidumps and Unix / Mach-O corefiles from LLDB down into LLVMCoreFile, write a library like llvm-core that can manipulate or inspect them, then have LLDB use it. Kill 2 birds with one stone that way IMO.

What about the case where you already have a Unix core file and you aren’t in a debugger but just want to convert it?

Just curious, would a small Python script using the LLDB SB API satisfy this requirement?

We could move all the code for consuming and producing Windows minidumps and Unix / Mach-O corefiles from LLDB down into LLVMCoreFile, write a library like llvm-core that can manipulate or inspect them, then have LLDB use it. Kill 2 birds with one stone that way IMO.

I like the idea of factoring out reusable subsystems, and I’d love to see something along these lines. Just a word of caution though: the hard part may not be the generation of a “structurally valid” minidump file, but “parsing” and modeling the process state (figuring out the list of modules & memory regions, etc. See the Crashpad implementation for details).

Greg already wrote a "save_crashlog" Python command that writes the state of the program as a macOS flavor Crashlog file. It's in examples/Python/crashlog.py. My guess is he had something similar to that in mind, but writing a mini dump file instead.

Jim

For core → minidump conversion, a Python tool might end up as trivial as:

process = target.LoadCore(source_core_file)

process.SaveMinidump(output_minidump_file)

Another angle on reusing existing minidump writing code: we could reuse just the minidump file creation from Crashpad (the part which constructs the minidump datastructures and puts together the final minidump file) without the “process parsing” part of Crashpad (since LLDB already covers that)

If anyone is interested in exploring that, the interface to this low level minidump writing part is crashpad::ProcessSnapshot & the rest of the xxxSnapshot interfaces.