Frysk and Core Dumps

Daylight! I managed to get some interesting initial code working last week. Finally managed to get the Frysk (Java based) API for representing core dumps into something usable (at least for .note data). It follows the Host = Machine, Proc = Process, Task = Thread abstract model that we already use to represent Linux Ptrace Hosts. So …

Host coreHost = new LinuxCoreFileHost(Manager.eventLoop, File(“your-core-file”));
Manager.eventLoop.runPending();

Will read in the core file, decipher the .notes segment, and build one Proc for the PRPSINFO header and data. After the Proc is built, it will add n amount of Tasks for each PRSTATUS it finds, and parent them to the Proc. It will also build the process auxv data from the AUX note entry. FPREGSET is not quite done yet, but “soon”.

After the core file is loaded into a Host, you might want to look at the process represented there. This can be done in the usual ways, via observers, finders or simply like:

Proc proc = coreHost.getProc(new ProcId(31497));

Now you can look at the process’s data (including process auxiliary data), the command line the process was executed with, the pid, ppid, sid, etc the process was operating under when it was core dumped. And lots more.

If you want to look at the threads that were owned by that process when it was core dumped, you can get the main thread using something like:

Task task = proc.getMainTask();

and all tasks via the getTasks() api.

To look at a thread’s register in a core file:

Isa isa = task.getIsa();
long ebx = isa.getRegisterByName(“ebx”).get(task)) ;
System.out.println(“ebx register = ” + ebx);

All of these interfaces are the same as the Frysk Ptrace interfaces, so slotting in a core file where a Ptrace process was previously used before, is just a matter of abstraction. My ultimate goal is when you load a core file into the Frysk UI, it will open the source browser, navigate to the fault location, show the code (and highlight the fault), and provide an interactive view of the backtrace.

There is still a lot of work to do, especially constructing the memory interface so that it is indistinguisable from a “live process” memory access, and also reconstructing the segments of the process map that were not captured in the corefile.

On another note, there is a new Frysk planet. There are also other Frysk bloggers busily writing articles. Sami Wagiaalla and Mike Cvet have been working on, and writing about the Frysk UI.

Copyright © Phil Muldoon

Built on Notes Blog Core
Powered by WordPress