https://bugs.kde.org/show_bug.cgi?id=528012
--- Comment #3 from Thomas Braun <[email protected]> --- Backtrace attached, generated from a coredump captured during the crash loop (2026-10-29 06:43:57 CET), with debug symbols from Arch's debuginfod server (akonadi 26.08.2, Qt 6.12.0). Crash site with symbols (crashing thread): #0 Akonadi::Server::Tracer::connectionOutput<Akonadi::Protocol::HelloResponse> at src/server/tracer.h:53 53 if (mTracerBackend->connectionFormat() == TracerInterface::Json) { #1 Akonadi::Server::Connection::sendResponse<Akonadi::Protocol::HelloResponse> at src/server/connection.h:147 #2 Akonadi::Server::Connection::slotSendHello at src/server/connection.cpp:113 #3 Akonadi::Server::Connection::init at src/server/connection.cpp:81 #4 Akonadi::Server::AkThread::startThread()::<lambda()> at src/server/akthread.cpp:55 #5+ Qt event delivery / glib main loop So with an unknown tracer value, mTracerBackend stays a null pointer (startup only logs "Unknown tracer type ..."). The crash then happens on the first incoming client connection: Connection::init() -> slotSendHello() -> sendResponse<HelloResponse>() -> Tracer::connectionOutput<HelloResponse>() dereferences the null backend at tracer.h:53. SIGSEGV, SEGV_MAPERR, rdi=0. Build-ID of akonadiserver: 6fbb337cbe284875265d4a2a7d9e12857336dbab The crash loop produced 51 coredumps overnight (3 per start attempt), i.e. the crash is 100% deterministic on every server start with this config value. Possible fix: reject unknown tracer types with a fatal configuration error at startup, or fall back to the null tracer backend (matching the behaviour of an absent [Debug] section). -- You are receiving this mail because: You are watching all bug changes.
