Review Request 128437: raise to core dump handlers when drkonqi is done

[Harald Sitter]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128437/
-----------------------------------------------------------

(Updated Sept. 28, 2016, 10:36 a.m.)


Review request for KDE Frameworks.


Changes
-------

discussed this a bit on IRC.

Given the fact that integrators might not wish to raise to a core handler we'll have a cmake option for this.
Presently the suggested rollout is that we'll have the raising disabled by default for 2 releases (opt-in) and then switched on by default (opt-out) so integrators can disable the re-raising if they either find it useless or counter productive to UX (e.g. handler UI conflicting with drkonqi UI).

This ultimately renders this a policy decision. Either one raises into the kernel and resolves potential UI conflicts by building better integration (e.g. https://community.kde.org/Kubuntu/QA/Whoopsie) or by simply not installing drkonqi to disable our UI, or one doesn't raise into the kernel and only uses drkonqi.

>From a platform POV it is more suitable for us to default to raising as this is the default behavior one would expect from a crashing application on posix systems. Small concession here is that we will not raise core file dumps (i.e. without handler process) to make it harder to litter the users hard disk with core dumps (I may be convinced that this should be an option though, currently no one presented a use case for this).


Repository: kcrash


Description
-------

with the rise of useful core dump handlers such as systemd's coredump and
ubuntu's apport it is no longer useful to handle things exclusively in
drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
putting the entire flow of information on us.

the new behavior instead checks if a core pattern executable is set and if
so re-raises the signal so the kernel jumps in and invokes the handler.

(this unfortunately means that the core will contain our kcrash frames,
but that seems hardly avoidable)


Diffs (updated)
-----

  CMakeLists.txt 21ccd1df72f6ab2e60bb3f8f9212359f1c24c53f 
  autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
  autotests/core_patterns/exec PRE-CREATION 
  autotests/core_patterns/no-exec PRE-CREATION 
  autotests/coreconfigtest.cpp PRE-CREATION 
  src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
  src/config-kcrash.h.cmake f1b3a9babda3e2220aed3c19b735f90eb1ea8e7e 
  src/coreconfig.cpp PRE-CREATION 
  src/coreconfig_p.h PRE-CREATION 
  src/kcrash.cpp d9acb591edb2232db6c9e0dc2726cf0f189823a0 

Diff: https://git.reviewboard.kde.org/r/128437/diff/


Testing
-------

builds and passes


Thanks,

Harald Sitter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160928/1bd43399/attachment.html>