On Mon, 07.05.12 16:25, Jan Kratochvil (jan.kratochvil@xxxxxxxxxx) wrote: > On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote: > > I just wrote a new Feature proposal for shipping minimal debug info by > > default: > > https://fedoraproject.org/wiki/Features/MiniDebugInfo > > The "several choices" is missing the primary possibility of no debug info > needed at the client side at all thanks to already implemented > https://fedoraproject.org/wiki/Features/RetraceServer > > Why not to use ABRT Retrace Server for the bugreports instead? > > I am only aware the upload of core file may be slow but that can be solved > (by gdbserver for core files, which was already implemeted once). I do not > know if it is a real problem or not, core file do not have to be large. It's already simply a scalability issue. Generating useful backtraces is not really something that is only and exclusively done when reporting a bug interactively, but is something that should be done automatically, without user input, on the individual machine, and should just be there, without having to keep coredumps, installing abrt or anything. The same way as kernel oops backtraces are always shown inline with other loggable information and are just there, we should log process backtraces in userspace too. Always, and on all systems, regardless in what state they are. And currently we can't do this. Having a centralized service that is bombared everytime any user of Fedora anywhere on the world runs into a coredump is just not how it makes sense to design a system. You don't want to centralize dispatching of something that can happen a million times a second all around the world. Right now, it is easier to make sense of a kernel oops without any special tools, than it is to make sense of a userspace segfault. And that's something that needs fixing, and what Alex helps us to do. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
