https://bugs.kde.org/show_bug.cgi?id=528012
Bug ID: 528012
Summary: akonadiserver SIGSEGV crash loop when [Debug] Tracer
is set to an unknown value (e.g. none)
Classification: Frameworks and Libraries
Product: Akonadi
Version First 6.8.2
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Setting an invalid tracer value in ~/.config/akonadi/akonadiserverrc:
[Debug]
Tracer=none
causes akonadiserver to crash with SIGSEGV on every start. After three crashes,
akonadi_control gives up ("crashed too often. Giving up!"), which takes down
the entire Akonadi/PIM stack (no agents, no data in Merkuro/KDE PIM apps,
calendar event creation fails).
none is not a valid tracer type — the valid no-op value is null — but it is a
plausible value a user might pick when trying to disable tracing. The failure
mode is disproportionate and hard to diagnose: the only hint is a single
Unknown tracer type "none" line in the journal per start, followed by an
unexplained segfault.
The crash is 100% deterministic and reproduces instantly.
Steps to Reproduce
Add the following to ~/.config/akonadi/akonadiserverrc:
[Debug]
Tracer=none
Restart the server: akonadictl restart (or akonadictl stop + akonadictl start)
Let any client connect (e.g. any Akonadi agent starting up, plasmashell,
Merkuro)
Observed Result
Journal on each start: Unknown tracer type "none"
akonadiserver reports "operational", then SIGSEGVs as soon as the first client
connects and sends a command
After 3 crashes: akonadiserver crashed too often. Giving up! — all Akonadi
agents die, the whole PIM stack is dead
coredumpctl shows SIGSEGV in akonadiserver (3 entries per attempt cycle)
Expected Result
The server should either reject the unknown tracer type with a clear fatal
error message and refuse to start, or silently fall back to the null tracer. A
configuration value must never crash the server — especially a value in a
debug/diagnostic section.
Workaround
Set Tracer=null (the valid no-op tracer) or remove the [Debug] section
entirely.
Software Versions
Arch Linux (EndeavourOS, rolling)
akonadi 26.08.2 (reproduced with both 26.08.2-2 and 26.08.1-1 distro packages)
Qt 6.12.0
MariaDB 13.0.2 backend
Plasma 6.8.1
Additional Information
The reproducer is independent of the database (reproduced with a fresh, empty
MySQL data directory), independent of the installed agents (reproduced with all
agent .desktop files removed from /usr/share/akonadi/agents), and independent
of the connecting clients.
The crash appears to occur in the connection thread when the first client event
is handled, consistent with the server running without a valid tracer backend
after the unknown-type fallback.
Backtrace: akonadi debuginfo is not available on Arch's debuginfod server, so
frames 0–2 remain unresolved in coredumpctl; the full coredump can be provided
on request.
No crash occurs with Tracer=file, Tracer=null, or with the [Debug] section
absent — only unknown tracer strings trigger it.
--
You are receiving this mail because:
You are watching all bug changes.
