rebuild of wxGTK without the internal crash handler in Rawhide

[Dan Horák]

Thomas Janssen píše v Pá 02. 07. 2010 v 13:21 +0200: 
> On Fri, Jul 2, 2010 at 12:58 PM, Dan Horák <dan at danny.cz> wrote:
> > Kevin Kofler píše v Pá 02. 07. 2010 v 04:06 +0200:
> >> Dan Horák wrote:
> >> > I will rebuild wxGTK without the internal crash handler for the the
> >> > devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> >> > apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> >> > this change affects all applications linked with wxGTK, because one
> >> > symbol is removed from the "base" library. I will take care of
> >> > rebuilding the packages in the next days, but the package owners should
> >> > still check what is their implementation of the
> >> > wxApp::OnFatalExpection() virtual method doing, because it will not be
> >> > called anymore. Usually it is used to display the wxGTK-based crash
> >> > report. Please let me know if you want to rebuild the package yourself
> >> > or if you have some questions.
> >>
> >> Do you really think this is a good idea? IMHO crash reports should go
> >> upstream, so using upstream's crash handler is a much better idea. ABRT
> >> spams our downstream Bugzilla with crash reports which really should go
> >> upstream instead. It's also technically nicer for the crash handler to be in
> >> the app, since it prevents having to dump core and then having an external
> >> process inspect the core dump.
> >
> > But the default crash handler only creates a text file with a rather
> > useless stack trace and the file is stored on the local computer.
> 
> This question might not be very popular, but do you really think that
> a, in your eyes useless stack trace (upstream obviously want that) is

what upstream? wxGTK upstream (who adds the default handler) is
generally not interested in crashed application. And the application
should build its own handler only if the symbol wxUSE_ON_FATAL_EXCEPTION
is defined by the wxGTK library as it's an optional functionality.

> any better than a useless ABRT backtrace? The not popular part comes
> in as the ABRT backtrace is useless as almost nobody of the
> packagers/maintainers are able to read it (me included) and upstream
> doesn't care about it. All that happens is that our BZ gets spammed
> with it. Yes, i'm a bit frustrated about this traces :-)
> 
> I really really would love to see at least one ABRT developer giving a
> class (we have #fedora-classroom for that) "how to read and understand
> ABRT backtraces".

The backtraces ABRT generates are not specific to ABRT, they are normal
backtraces from gdb, so anyone with enough gdb and debugging knowledge
could do it. ABRT ensures that the backtrace is generated with debug
information installed meaning it will contain more useful information.


Dan