On Mon, 07 May 2012 17:40:18 +0200, Lennart Poettering wrote: > on the individual machine, There is no backing reason for this requirement. It does not matter where. > without having to keep coredumps, Core dump currently always have to be shortly stored on the disk anyway, even for using minidebuginfo. Backtracing crashed program without dumping its core would be a different project. > And currently we can't do this. Unfortunately this is not possible with all your requirements due to: * Even the optimal full debuginfo size (Jakub's dwz) is still only IIRC ~50% of the current debuginfo size, which is still not suitable to install for every package on every machine. * Opinions to this item significantly differ but minidebuginfo-only backtraces are in many (IMO most) cases not usable for problem analysis. > Having a centralized service that is bombared everytime any user of > Fedora anywhere on the world runs into a coredump There are some efforts from ABRT team to discard duplicate crashes already before uploading them. > You don't want to centralize dispatching of something that can happen > a million times a second all around the world. Unique crashes do not happen so often. > Right now, it is easier to make sense of a kernel oops without any > special tools, Kernel is a very specific package and its behavior and coding style cannot be automatically generalized to other packages. > And that's something that needs fixing, and what Alex helps us to do. I agree we should fix it but I believe there are better options to do so. Primarily ABRT Retrace Server is already deployed and I still have not heard why not to use its significantly better debug info backtraces quality compared to this symtab-only poor backtraces. Thanks, Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
