Fwd: kcrash core pattern raising in 5.27+
Philip Muskovac
yofel at gmx.net
Wed Oct 5 15:36:11 UTC 2016
What should be happening IMO is that the apport window should be hidden
if drkonqi already handled the error, but the crash should be passed
through to the tool that sends the data to Canonicals error tracker
(still whoopsie?). That way we could keep track of crashes without the
user seeing
multiple windows.
Actually Harald probably knows best how to do this ^^
Philip
Am 05.10.2016 um 03:09 schrieb Simon Quigley:
> How are we going to leverage this? What's our plan here?
>
>
> -------- Forwarded Message --------
> Subject: kcrash core pattern raising in 5.27+
> Date: Tue, 4 Oct 2016 13:52:07 +0200
> From: Harald Sitter <sitter at kde.org>
> To: kde-distro-packagers at kde.org
>
> Hola
>
> Last week I added a new feature to kcrash which allows re-raising
> terminal signals to the native core pattern handler process. Namely,
> this allows system administrators to catch traces via coredump and
> friends.
>
> This feature is in addition to the existing drkonqi report mechanism
> we have in place.
>
> While this is currently opt-in, the plan is to have this be the
> default behavior by 5.29. As such there are some UX concerns you may
> have to deal with on a distribution level. I know that at least Fedora
> and Kubuntu have a distribution crash aggregator set as default core
> handler. While this is not a problem in of itself, you may wish to
> review the UX implications of having drkonqi and raising into a distro
> handler.
>
> Actual example from Kubuntu: crashes aggregated by the apport core
> handler will result in the apport UI reporting that something crashed
> and asking if the user wishes to send the core dump to Canonical for
> tracking, since this ultimately duplicates what drkonqi did (albeit on
> a distro level) either drkonqi or the apport UI should be disabled or
> a tight integration should be created [1].
>
> So, I suggest you review if your distribution has a core handler by
> default. And decide what you want to happen.
>
> - If you cannot feasibly raise into that handler, explicitly set
> -DKCRASH_CORE_PATTERN_RAISE=OFF (do note that this impairs sysadmin's
> ability to use handlers, so if you find this necessary we should have
> a talk about the specifics)
>
> - If your handler has a UI attached to it, either do not install
> drkonqi (all crashes will go through your handler UI this way) OR
> don't show the handler UI on crashes out of kcrash (kcrash symbols
> will the second to last frame of the current thread) OR form a unified
> user experience as outlined in [1]. Until you are sure this is sorted
> I'd also advise to explicitly set -DKCRASH_CORE_PATTERN_RAISE=OFF
>
> - If none of the above applies and you either install coredump by
> default or no handler by default you can enable this feature already
> via -DKCRASH_CORE_PATTERN_RAISE=ON
>
> [1] ex of integrated handling employed in kde4 times
> https://community.kde.org/Kubuntu/QA/Whoopsie
>
>
>
More information about the kubuntu-devel
mailing list