Retrace server incremental improvements
Reason for existence
Issues this project is addressing:
- When third-party systems use retrace server to generate a
backtrace to search Red Hat Bugzilla for duplicates, they also
need a duphash of the generated backtrace. Duphash is generated by
the btparser library from a backtrace and a component name, both
of which are known by retrace server. Btparser is written in C,
and it is unnecessarily laborious to use it from Java code, so
Java system will benefit from providing duphash together with the
backtrace from the retrace server.
- Backtrace rating should be returned by the retrace server for
the same reason. It can be used by third-party systems to filter
out low-quality backtraces.
- Sometimes a backtrace generated by retrace server does not
provide enough information to find corresponding source code flaw,
but custom GDB session on the coredump would provide it.
- Retrace server doesn't handle system-wide dumps (vmcores),
although the vmcore issues are very similar to those that retrace
server solves for coredumps.
- Sometimes a coredump of a program crash is provided without
using ABRT. Users would like to use retrace server to convert
those coredumps to backtraces, without knowing additional
information such as Fedora version and component name.
- Retrace server does not provide enough information about
retracing failures.
- Retrace server sometimes fails to find good combination of
packages to be installed into chroot. This causes either a yum
failure (no chroot is installed at all), or incomplete backtrace
being generated.
Objectives
- Provide duphash and quality rating together with every
backtrace.
- Allow users to initiate an interactive GDB session, send
commands to GDB and obtain results.
- Allow retracing of vmcores.
- Accept and retrace coredumps without additional metadata.
- Provide logs that allows figuring out why a retracing job failed
publicly.
- Improve dependency resolution quality.
Outcomes
- coredump2packages
- Use libsolv for package dependency resolution
- Provide package name, component name, full installable
package set
- Coredump processing log must include time measurements
People
- Team: Michal Toman, Karel Klíč
- External help people: Jindra Nový
- Send information to: Jirka Moskovčák, Radek Vokál
Timeline
- Project start date: 2011-08-23
- Planned finish date: 2012-04-30
Diary
- 2011-11-14
- coredump2packages: Added time measurements to logging
Contingency plan
None.
Documentation
Homepage