https://bugs.kde.org/show_bug.cgi?id=477115
Bug ID: 477115
Summary: KCrash interferes with QProcess::exitStatus
Classification: Frameworks and Libraries
Product: frameworks-kcrash
Version: 5.112.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: fa...@kde.org
Reporter: stefan.bru...@rwth-aachen.de
CC: kdelibs-b...@kde.org
Target Milestone: ---
SUMMARY
Whenever KCrash catches e.g. SIGSEGV or SIGILL, it may either reraise the
signal after DrKonqi has closed, or do an `_exit(253)`.
Which of the two happens depends on the setting of
/proc/sys/kernel/core_pattern.
STEPS TO REPRODUCE
1. execute an external program which uses KCrash using QProcess::start(...)
(a program known to crash - for a reproducer, just use `raise(SIGSEGV)`).
2. listen to the `QProcess::finished(...)` signal
3. Evaluate the `QProcess::exitStatus`
OBSERVED RESULT
The `exitStatus` should be `QProcess::CrashExit`
EXPECTED RESULT
The `exitStatus` *may be* `QProcess::NormalExit` with an exitCode of 253.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.112.0
KDE Frameworks Version: 5.112.0
Qt Version: 5.15
ADDITIONAL INFORMATION
When `systemd-coredump` is installed, the `core_pattern` is set to a pipe.
The intention seems to not produce a core file when a crash is caught by
KCrash. There a other ways to achieve this, as outlined in `man 5 core`, e.g.
setting the RLIMIT_CORE to { 0, 0 }.
This behavior is not mentioned in any documentation, at least not in
https://api.kde.org/frameworks/kcrash/html/namespaceKCrash.html
--
You are receiving this mail because:
You are watching all bug changes.
