On Tue, 05 Oct 2010 17:44:36 +0200, Karel Klic wrote:
A client sends a coredump (created by Linux kernel) together with
additional information to the server, and gets a backtrace generation
Is this the only planned mode for ABRT? I would find it only as an additional
mode of operation. I may not want to send my core files anywhere. And for
some users and/or applications it may be many times faster to backtrace them
Why is not discussed the idea of some core-at-client <-> gdb-at-retrace-server
network protocol instead of the full upload to the retrace server?
Only secure (HTTPS) communication must be allowed for the
communication with abrt-retrace-server,
There should be specified a way how the certificates will be verified.
To support multiple architectures, the retrace server needs a GDB
package compiled separately for every supported target architecture
(see the avr-gdb package in Fedora for an example).
x86_64 gdb suports even 32bit x86 core files. GDB currently requires native
target support for reading core files:
That is x86/x86_64 GDB cannot backtrace non-x86/x86_64 core files anyway.
This is technically and economically better solution than using a
machine for every supported architecture and re-sending coredumps depending
on client's architecture.
Unless GDB gets a fix this has to be done.
Also one can probably build a custom multi-target GDB instead of starting new
cross-GDB packages one for each non-x86* platform targets.
The following files from the local crash directory are required to
present in the archive: coredump, architecture, release,
packages (this one does not exist yet).
If you mean `rpm -qa' then the core file already contains build-ids. Support
should go that way as build-id is more safe than possibly ambiguous NEVRA.
build-id is also cross-distro safe.
Tasks that were created more than 5 days ago must be deleted,
tasks occupy disk space (not so much space, because the coredumps are
deleted after the retrace,
This may be offtopic but I miss the feature of sending also the core dump.
Currently I sometimes have to ask the reporter to find it and I am often told
the core file is not in /var/spool/abrt . The user possibly may not have
found it, and also it should be easier for the user than sending it by hand.
I understand sending the core files should require some special confirmation.
The retrace-server storage may be a safe storage between the time of report,
assignee's failed backtrace analysis - core dump request by assignee and the
reporter's core dump unlock for the core dump analysis by assignee.
The worker prepares a new "chroot" subdirectory with the
their debuginfo, and gdb installed. In other words, a new directory
/var/spool/abrt/retrace/<id>/chroot is created and the packages are
unpacked or installed into this directory,
As most of the crashes share the same package versions set it should be more
effective to share/reuse such chroot for multiple core dumps.
File permissions / UIDs should be enough for the security of such setup.
The GDB installed into the chroot must be able to:
- run on the server (same architecture)
- process the coredump (possibly from another architecture): that
means we need a special GDB for every supported architecture
- use libc, zlib, readline, ncurses, expat and Python packages, while
the version numbers required by the coredump might be different from
what is required by the GDB
The gdb might fail to run with certain combinations of package
GDB has full support for separate trees of files. See `set sysroot',
`set debug-file-directory', `set solib-search-path'.
There should be the most recent single GDB version at the retrace server.
Packages should not be _installed_ to the chroot, they should be
only, because we use them as a data source, and we never run them.
Besides other issues the *-gdb.py pretty printings scripts must work,
therefore a fully working crashdump-versioned system must be prepared.
We should support every Fedora release with all packages that ever
made it to the updates and updates-testing repositories. In order to
provide all that packages, a local repository is maintained for every
supported operating system.
A repository with Fedora packages must be maintained locally on the
server to provide good performance and to provide data from older
packages already removed from the official repositories.
Such feature is required also for individual bug triagers to get the same
package versions setup as the reported for problem reproducibility when no
backtrace/coredump is usable/available. So far FESCo has pointed me to:
I believe it would be insufficient but I have not proven it so far.
Can the retrace server trust clients? We must know what can a
malicious client achieve by crafting a nonstandard coredump, which
will be processed by server's GDB. We should ask GDB experts about
There was CVE-2006-4146 (IMO exploitable also through a core file).
But this would be a security hole which is generally not expected.
The retrace server uses the nonstandard packages together with the
packages to generate the backtrace. Is it safe?
As GDB loads *-gdb.py scripts supplied by applications it is not.