alnovak
crashsite
a project by alnovak
Examining vmcore with crash (very) often means to look at multiple outputs at once, which in console enviroment simply is not easily achievable. Since last hackweek, there is a
gdb-kdump
a project by alnovak
The goal of the project is making the gdb able to open compressed kernel dump - access its memory contents at the very least. If one wants to open compressed kernel dump (that's what our customers are sending mostly when reporting kernel panics nowadays), he has to use crash. Crash is a brilliant tool with many kernel-specific hacks, but at the same time, it has a huge functionality overlap with gdb, it is hard (even impossible in many cases) to extend it.
gdb - better disassembly
a project by alnovak
The disassembly in gdb is not ideal. The binding with source code lines is weird (even crash, which does use gdb beneath, does that better), I don't see the jump targets; furthermore, there's a lot more informations hidden in the DWARF2 which may be of some interest - like which code is inlined, or which register/stack address should contain some variable. My goal is to search for a way how to improve that.
libkdumpfile/gdb-kdump improvements
a project by alnovak
gdb-kdump (and libkdumpfile) needs a plenty of improvements and tasks to be done. For HackWeek 13, Vlastimil chose to work on SLAB memory support, Petr, amongst other things, reorganized the libkdumpfile code and alnovak begun with libkdumpfile's ppc64 support. Our status in 4/5 of HackWeek 13:
SLAB
gdb python target / binding to libkdumpfile
a project by alnovak
Our previous efforts to enable gdb to open kdumps was not received in upstream as well as we hoped for. The perhaps-acceptable way would be to extend gdb with the possibility of implementing targets in Python, then create example binding to libkdumpfile (which already got a Python binding). We've already tried that, yet it has to be tidyed up. So this project aims at:
Fast bugzilla search
an invention by alnovak
The Problem
The first thing one should do when resolving a bug is to find out, whether that bug wasn't encountered and perhaps even fixed before. Using our internal Bugzilla's search, that can be long and painful task. I don't know if I'm querying it wrong, or if the problem is the amount of bugs (> 1M and growing quickly), or the number of users, or simply the Bugzilla itself. Also another problem is that some bugs have wrong metadata, which makes the efforts to narrow the search a bit harder.
Investigate debuginfod & cores from SLES
a project by alnovak
It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing. However this sounds like a bit of an overkill. Lately, there has been a debuginfod project announced:
Looking for projects around:
Nothing at the moment
Activity