rebuild of wxGTK without the internal crash handler in Rawhide

Kevin Kofler kevin.kofler at chello.at
Fri Jul 2 02:06:37 UTC 2010


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.

FWIW, we have no plans to disable KCrash/DrKonqi in KDE at this time. We're 
already having enough trouble with the small percentage of crashes which 
makes it through to ABRT for whatever reason (non-GUI KDE apps (which cannot 
currently use KCrash because it's in kdeui), kdesupport stuff, recurring 
crashes in autorespawned stuff like plasma-desktop (where KCrash gets 
disabled on respawn to prevent infinite respawning loops), KCrash itself 
crashing (ugh!)), since those are still hundreds of bugs!

        Kevin Kofler



More information about the devel mailing list