https://bugs.kde.org/show_bug.cgi?id=524094
Bug ID: 524094
Summary: openSUSE Tumbleweed 20260806 — Kontact shutdown crash
and associated PIM findings
Classification: Applications
Product: kontact
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: mail
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
**Audience:** openSUSE Tumbleweed KDE/PIM maintainers, Factory reviewers,
QA/openQA, and upstream KDE PIM developers
**Diagnostic source:** `scc_johns-pc.local_260810_1640.txz`
**Supportconfig collected:** 10 August 2026
**System snapshot:** openSUSE Tumbleweed `20260806`
**Desktop session:** Plasma 6 / Wayland
**Purpose:** distinguish confirmed upstream defects from local
configuration/database problems and identify useful Tumbleweed development/QA
actions.
---
# 1. Executive summary
The most significant fault in this supportconfig is a **reproducible Kontact
process-exit heap corruption**.
Two independent Kontact coredumps, from different boots on **31 July 2026** and
**1 August 2026**, terminate with:
```text
corrupted size vs. prev_size while consolidating
SIGABRT
```
Both crashes have effectively identical fatal destruction paths:
```text
QV4::ExecutableCompilationUnit
→ QV4::ExecutionEngine
→ QJSEngine
→ KTextTemplate::ScriptableTagLibrary
→ GrantleeTheme::Engine
→ MessageViewer::MessagePartRendererManager
→ __run_exit_handlers
→ exit
```
This matches **KDE Bug 519219**, which KDE has classified as a high-priority
Kontact crash and marked **RESOLVED FIXED**. The upstream report is also from
openSUSE Tumbleweed and reproduces when quitting Kontact. KDE Bugzilla
currently records nine duplicate reports.
Upstream fixed the lifetime/destruction ordering in both `grantleetheme` and
`messagelib`. The fixes have been cherry-picked into the `release/26.08`
branch, and KDE Bugzilla records the implemented version as **6.8.0**.
The local installation is still:
```text
akonadi 26.04.3-1.2
kontact 26.04.3-1.2
kmail 26.04.3-1.2
messagelib 26.04.3-1.2
grantleetheme 26.04.3-1.2
libKPim6GrantleeTheme6 26.04.3-1.2
Qt Core/QML 6.11.1-1.3
KF6 KTextTemplate 6.28.0-1.2
MariaDB 12.3.2-1.3
```
At **16:42 on 10 August**, the captured `zypper` output reported:
```text
No updates found.
```
Therefore this is not a case of an affected user simply failing to apply an
available Tumbleweed update.
### Primary recommendation
**Either deliver KDE PIM 26.08/6.8 containing the upstream fix, or consider a
reviewed Tumbleweed backport of the two targeted upstream fixes if 26.08 cannot
reach users promptly.**
There is no evidence that deleting/rebuilding Akonadi, changing MariaDB,
changing IMAP configuration, or changing Btrfs configuration would correct this
crash.
---
# 2. Severity and triage
| Priority | Issue |
Assessment |
| --------- | ----------------------------------------------------- |
--------------------------------------------------------------------- |
| **P1/P2** | Kontact SIGABRT on process exit | Confirmed
upstream defect; strong exact stack match |
| **P2** | Akonadi private MariaDB killed after shutdown timeout | Genuine
separate reliability issue; seen once |
| **P2/P3** | 422 unmatched Qt model-reset warnings |
Systematic PIM/Akonadi model-lifecycle defect deserving investigation |
| **P3** | QtWebEngine/NSS root-cert error `-8018` |
Cross-application issue; not specific to KMail/Kontact |
| **P3** | HTML/CSS/font/image parser warnings | Mostly
malformed mail-content tolerance/noise |
| — | Akonadi SQL/database corruption | Not
supported by evidence |
| — | OOM/RAM/NVMe/storage exhaustion | Not
supported by evidence |
| — | SELinux blocking KDE PIM | Not
supported by evidence |
| — | IMAP/OAuth failure | Not
supported by captured logs |
---
# 3. Confirmed defect: Kontact shutdown heap corruption
## 3.1 Local crash #1
```text
Timestamp: Fri 2026-07-31 17:54:21 NZST
Executable: /usr/bin/kontact
Signal: 6 (ABRT)
Core size: 32.4 MiB
```
Journal:
```text
kontact[74229]: corrupted size vs. prev_size while consolidating
```
Important coredump frames:
```text
#11 QV4::ExecutableCompilationUnit::~ExecutableCompilationUnit
#13 QV4::ExecutionEngine::~ExecutionEngine
#15 QJSEnginePrivate::~QJSEnginePrivate
#16 QJSEngine::~QJSEngine
#19 KTextTemplate::ScriptableTagLibrary::~ScriptableTagLibrary
#22 GrantleeTheme::Engine::~Engine
#23 MessageViewer::MessagePartRendererManager::~MessagePartRendererManager
#24 __run_exit_handlers
#25 exit
```
---
## 3.2 Local crash #2
```text
Timestamp: Sat 2026-08-01 09:04:48 NZST
Executable: /usr/bin/kontact
Signal: 6 (ABRT)
Core size: 45.4 MiB
```
Journal:
```text
kontact[12055]: corrupted size vs. prev_size while consolidating
```
The destruction path is effectively identical:
```text
QV4::ExecutableCompilationUnit
QV4::ExecutionEngine
QJSEngine
KTextTemplate::ScriptableTagLibrary
GrantleeTheme::Engine
MessageViewer::MessagePartRendererManager
__run_exit_handlers
exit
```
Two occurrences on separate boots make accidental one-off heap corruption
considerably less likely.
---
# 4. Exact upstream correlation
KDE Bug **519219** describes a Kontact SIGABRT on openSUSE Tumbleweed with Qt
6.11. The upstream crash contains the same QML/QV4 destruction area and is
reproducible during application quit. Upstream also reports that the individual
applications such as KMail and KOrganizer do not reproduce the same
Kontact-shell exit crash.
The bug was reported on **21 April 2026** against Kontact 26.04.0, well before
this machine's later 26.04.3 package rebuild. This is important when
interpreting the local package history: the problem should not be assumed to
have been introduced by openSUSE's `26.04.3-1.2` rebuild.
Upstream identified singleton destruction ordering as the immediate problem.
### GrantleeTheme fix
Upstream commit:
```text
74cca072c1d8a89056df30473aaaf270ba7f2377
```
Release/26.08 cherry-pick:
```text
02ee5e67afdc95e918c2869245261a073f1910f0
```
The change arranges for `GrantleeTheme::Engine` to be explicitly reset while
the application is still in a controlled `aboutToQuit` phase rather than
leaving it to late static/process teardown.
### MessageViewer/messagelib fix
Upstream commit:
```text
042250f37274bcefef7828f1cd9069260e8c5e46
```
Release/26.08 cherry-pick:
```text
652583f6a94a2e038da60d4d0d65a3d3e228e76e
```
This explicitly disposes of `MessagePartRendererManager` during application
quit.
These are precisely the two KDE PIM objects visible immediately above the
process-exit handlers in both Tumbleweed coredumps.
KDE describes the 6.8 solution as an interim lifetime fix, with a better
architectural solution intended for the later 6.9 development cycle.
### Confidence
**Very high.**
This is not merely a similar SIGABRT:
* same application;
* same operating distribution family;
* same Qt 6.11 generation;
* same process-exit context;
* same QV4/QJSEngine destruction;
* same GrantleeTheme component;
* same MessagePartRendererManager component;
* upstream commits specifically alter the lifetime of those exact objects.
---
# 5. Recommended Tumbleweed packaging action
## Preferred resolution
Ship the normal KDE Gear/PIM **26.08 / application version 6.8.x** packages
containing the two fixes.
## If the fixed release cannot be delivered promptly
Maintainers could evaluate backporting the two small upstream lifetime fixes to
the affected Tumbleweed 26.04 package set.
This should be a maintainer-reviewed backport rather than assuming the 26.08
patches apply unchanged to 26.04.
Packages requiring coordinated consideration are at least:
```text
grantleetheme
messagelib
```
The Tumbleweed package set should remain version/ABI coherent with:
```text
kontact
kmail
akonadi
grantleetheme
messagelib
```
A package changelog entry should reference KDE Bug 519219 so subsequent
regressions are easy to correlate.
---
# 6. Recommended QA/openQA regression test
This failure is unusually suitable for an automated KDE PIM smoke test because
the crash happens during destruction rather than requiring a complex
mail-server failure.
A Tumbleweed KDE PIM test should exercise:
1. Start an Akonadi-enabled Plasma session.
2. Start Kontact rather than only standalone KMail.
3. Load the KMail component.
4. Allow MessageViewer/Grantlee theme components to initialize.
5. Preferably display at least one HTML message.
6. Quit the complete Kontact application.
7. Verify clean exit.
8. Check the journal/coredump database for a new Kontact SIGABRT.
9. Repeat the launch/quit sequence multiple times.
The important distinction is **Kontact shell versus standalone KMail**. Testing
only `/usr/bin/kmail` may fail to expose KDE Bug 519219; the upstream report
specifically distinguishes the integrated Kontact process from the standalone
PIM applications.
For a development/debug image, repeating the test with allocator diagnostics
enabled would improve sensitivity to destruction-order defects.
Useful candidates include:
```text
GLIBC_TUNABLES=glibc.malloc.check=3
MALLOC_PERTURB_=165
```
An AddressSanitizer KDE PIM build would provide stronger evidence if a related
lifetime fault remains after the upstream fix.
### Acceptance criterion
No:
```text
SIGABRT
corrupted size vs. prev_size
QV4::ExecutableCompilationUnit teardown failure
MessagePartRendererManager teardown crash
GrantleeTheme::Engine teardown crash
```
after repeated Kontact exits.
---
# 7. Akonadi database integrity: no corruption found
Akonadi should not be treated as the cause of the Kontact coredumps without
additional evidence.
The supportconfig shows repeated Akonadi/MariaDB table checks returning `OK`,
including after the recorded abnormal Akonadi shutdown.
Representative checked tables include:
```text
collectionattributetable
collectiontable
flagtable
mimetypetable
parttable
parttypetable
pimitemtable
resourcetable
schemaversiontable
tagattributetable
tagremoteidresourcerelationtable
tagtable
tagtypetable
```
The table checks are clean on multiple startups, including:
```text
6 August
7 August
8 August
9 August
10 August
```
The latest captured startup on 10 August again shows:
```text
akonadi.pimitemtable OK
akonadi.schemaversiontable OK
...
```
No supporting evidence was found for:
```text
SQLSTATE errors
missing tables
missing columns
duplicate-key corruption
deadlocks
lock-wait timeouts
QMYSQL initialization failures
MariaDB "server has gone away"
failed schema migration
```
### Developer conclusion
Please avoid recommending an Akonadi database rebuild as the first-line
response to this particular Kontact crash signature.
Deleting:
```text
~/.local/share/akonadi
```
would destroy useful state and does not address the failing process-exit
ownership path.
---
# 8. Separate issue: Akonadi shutdown timeout
A real but apparently independent Akonadi failure occurs on:
```text
2026-08-02 10:48:03 +12:00
```
systemd reports:
```text
akonadi_control.service:
State 'final-sigterm' timed out. Killing.
akonadi_control.service:
Killing process 2171 (mariadbd) with signal SIGKILL.
akonadi_control.service:
Failed with result 'timeout'.
```
This is worth investigation because killing Akonadi's private MariaDB with
SIGKILL is undesirable even when crash recovery succeeds.
However:
* only one such Akonadi timeout was identified in the captured period;
* subsequent Akonadi startups succeeded;
* subsequent MariaDB/Akonadi table checks were clean;
* it does not correspond to the two Kontact SIGABRT backtraces.
### Recommended treatment
Track this as a **separate issue** from KDE Bug 519219.
Useful development questions:
* Does `akonadictl stop` terminate promptly when run before Plasma logout?
* Is the delay in `akonadi_control`, `akonadiserver`, or private `mariadbd`?
* Are active IMAP/resource jobs preventing shutdown?
* Does the issue remain after KDE PIM 26.08?
* Does systemd's shutdown ordering race with Akonadi resource termination?
* Would more shutdown-phase logging expose which process/socket remains active?
If the timeout becomes reproducible, capture:
```bash
journalctl --user -u akonadi_control.service -b
systemctl --user status akonadi_control.service
akonadictl stop
```
with accurate elapsed shutdown timing.
---
# 9. Separate issue: systematic Qt model-reset protocol warnings
The journal contains **422** warnings involving unmatched Qt model reset
operations.
Distribution:
```text
kalendarac 312
akonadi_mailfilter_agent 52
akonadi_archivemail_agent 52
kontact 6
-------------------------------
total 422
```
Examples include:
```text
endResetModel called on Akonadi::EntityTreeModel(...)
without calling beginResetModel first
```
and:
```text
beginResetModel called on Akonadi::TodoModel(...)
without calling endResetModel first
```
Affected classes include:
```text
Akonadi::EntityTreeModel
Akonadi::EntityMimeTypeFilterModel
Akonadi::CalendarModel
Akonadi::CollectionFilterProxyModel
Akonadi::CheckableProxyModel
Akonadi::CalFilterProxyModel
Akonadi::CalFilterPartStatusProxyModel
KSelectionProxyModel
Akonadi::TodoModel
QIdentityProxyModel
TodoViewSortFilterProxyModel
```
These warnings appear systematically across agents and `kalendarac`, rather
than being one isolated application message.
### Assessment
They do **not** explain the two fatal Kontact crashes because the fatal stack
has a separately confirmed Grantlee/MessageViewer teardown cause.
They should nevertheless not be dismissed as normal journal noise. They
indicate incorrect model-reset sequencing or an object/model destruction path
that causes Qt to observe unmatched reset state.
### Recommended developer work
Create a separate Akonadi/PIM investigation.
A useful debug build could run the affected agent with Qt warnings promoted to
fatal errors so that the **first invalid reset sequence produces a stack
trace**, rather than collecting hundreds of later warnings.
For development/testing only:
```text
QT_FATAL_WARNINGS=1
```
would be useful when the warning can be narrowly reproduced.
The goal should be to identify the first incorrect `beginResetModel()` /
`endResetModel()` transition, not merely suppress the warning.
This is particularly worthwhile with Qt 6.11 because systematic model protocol
violations may expose lifetime or proxy-model assumptions that happened to be
tolerated previously.
---
# 10. QtWebEngine/NSS `-8018` warning
There are **191** occurrences of:
```text
After loading Root Certs, loaded==false:
NSS error code: -8018
```
Breakdown:
```text
Kontact 146
Google Chrome 45
-------------------
Total 191
```
The same warning occurring in both Kontact's QtWebEngine code and Google Chrome
is strong evidence that this is **not specifically an Akonadi or KMail
defect**.
### Recommendation
Do not block the Kontact fix on this warning.
If users also experience:
```text
TLS/certificate failures
HTTPS failures
remote HTML failures
certificate-store problems
```
then investigate the NSS/PKCS#11/root-certificate packaging path separately.
Without such user-visible failures it should remain a lower-priority
packaging/runtime warning.
---
# 11. Email-rendering warnings
The logs contain many parser/rendering diagnostics such as:
```text
QTextHtmlParser::applyAttributes: Unknown color name
QCssParser...
QFont::setPixelSize: Pixel size <= 0
libpng warnings
QtWebEngine JavaScript console messages
```
Much of this appears to be triggered by malformed or non-standard
HTML/CSS/images contained in received messages.
These warnings may be useful for MessageViewer robustness work but they do not
correlate with the two fatal destruction stacks.
### Development opportunity
For a mail client, malformed remote content should ideally produce:
* bounded warning output;
* no unbounded journal spam;
* no crash;
* sane CSS fallback;
* safe image-decoder behaviour.
Reducing duplicate warning volume would improve the diagnostic signal available
in supportconfig reports.
---
# 12. Environmental causes excluded by the supportconfig
## Memory/OOM
No relevant OOM kill was found.
```text
OOM hits relevant to this incident: 0
```
The Kontact processes terminate through glibc allocator corruption detection,
not kernel memory pressure.
## SELinux
No relevant AVC denials involving Kontact, KMail or Akonadi were found.
## NVMe
The NVMe device reports:
```text
SMART overall-health: PASSED
Critical Warning: 0x00
Media and Data Integrity Errors: 0
```
## Filesystem capacity
`/home` has approximately:
```text
477 GiB total
261 GiB used
214 GiB available
56% used
```
There is no storage-exhaustion condition explaining database or Kontact
failure.
## Btrfs quotas
The supportconfig reports quotas currently disabled.
Older qgroup-related messages are not temporally or technically correlated with
the Kontact teardown crash.
## Mail resources
The captured Akonadi resource stack is active, including IMAP and Google
resources.
XOAUTH2 exchanges are visible but the logs do not show corresponding
authentication rejection, invalid credentials, connection refusal, or
resource-process crash explaining the Kontact SIGABRT.
---
# 13. Package chronology
On **30 July 2026**, relevant KDE PIM packages were rebuilt/updated from
openSUSE revision:
```text
26.04.3-1.1
```
to:
```text
26.04.3-1.2
```
The recorded Kontact crashes followed on:
```text
31 July
1 August
```
This chronology initially resembles a possible Tumbleweed packaging regression.
However, KDE Bug 519219 had already been reported in April against Kontact
**26.04.0**, with essentially the same failure family.
### Conclusion
Do not spend significant effort bisecting only the openSUSE `-1.1 → -1.2`
rebuild unless testing with the two upstream fixes disproves the current
diagnosis.
The strongest evidence points to an upstream 26.04 lifetime bug rather than an
openSUSE-only rebuild defect.
---
# 14. Suggested developer validation matrix
| Test | 26.04.3 current | 26.04.3 +
backported fixes | 26.08/6.8 | Expected |
| -------------------------------- | -------------------- |
-------------------------- | ------------- | ------------ |
| Launch standalone KMail | Test | Test
| Test | Clean |
| Quit standalone KMail | Test | Test
| Test | Clean |
| Launch Kontact + KMail component | Test | Test
| Test | Clean |
| Render HTML mail | Test | Test
| Test | Clean |
| Quit Kontact repeatedly | **Known failure** | Critical test
| Critical test | Clean |
| Check `coredumpctl` | Two historical cores | None new
| None new | None |
| Akonadi DB check | Clean | Clean
| Clean | Clean |
| Akonadi logout shutdown | One timeout seen | Retest
| Retest | Clean |
| Model-reset warnings | 422 captured | Compare
| Compare | Ideally zero |
The most valuable comparison is:
```text
current 26.04.3
vs.
same environment with only the two lifetime fixes
```
That would confirm causality independently of the larger 26.08 upgrade.
---
# 15. Suggested regression criteria for KDE PIM updates
Before promoting a major KDE PIM/Qt combination in Tumbleweed, a useful minimum
automated stability gate would include:
### Startup
```text
akonadi_control starts
akonadiserver starts
private MariaDB starts
configured resources become available
Kontact starts
KMail component loads
```
### Runtime
```text
mail collection model loads
message viewer initializes
HTML message displays
calendar model initializes
Akonadi agents remain alive
```
### Shutdown
```text
Kontact exits normally
MessageViewer tears down normally
GrantleeTheme engine tears down normally
QJSEngine tears down normally
Akonadi shuts down within systemd timeout
private MariaDB exits without SIGKILL
no new coredumps
```
### Journal quality
Flag unexpected growth in:
```text
beginResetModel/endResetModel violations
QObject lifetime warnings
SQL/database errors
NSS initialization failures
resource crashes
```
This would catch several classes of KDE PIM regression that ordinary
package-install/open-window testing will miss.
---
# 16. Actions requested from openSUSE maintainers
## Immediate
1. **Confirm KDE Bug 519219 applies to Tumbleweed's current 26.04.3 packages.**
2. Confirm that the upcoming/current 26.08 package set contains both upstream
fixes.
3. Consider a short-lived backport if users will otherwise remain exposed to
the crash for a significant period.
4. Avoid recommending Akonadi database deletion for this crash signature.
5. Add a Kontact **quit/teardown** regression test, not merely an
application-start test.
## Separate follow-up
6. Investigate the Akonadi/private-MariaDB shutdown timeout if it can be
reproduced.
7. Investigate the 422 unmatched Qt model-reset warnings independently of the
Kontact crash.
8. Treat the NSS `-8018` warning as a cross-application QtWebEngine/NSS issue
rather than assigning it initially to Akonadi.
9. Consider reducing excessive MessageViewer parser-warning duplication to
improve supportconfig diagnostic quality.
---
# 17. What would constitute successful resolution
After a fixed KDE PIM update:
```bash
rpm -q kontact kmail akonadi messagelib grantleetheme
```
should show the fixed package set.
Then repeatedly exercise Kontact and check:
```bash
coredumpctl list kontact
```
There should be no new Kontact coredumps.
Akonadi startup should continue to report healthy tables.
System shutdown/logout should not contain:
```text
akonadi_control.service:
State 'final-sigterm' timed out
Killing process (...) (mariadbd) with signal SIGKILL
```
The model-reset warning count should also be compared before and after the KDE
PIM update.
---
# 18. Final engineering assessment
### Confirmed
The two Kontact SIGABRT events are almost certainly the known upstream **KDE
Bug 519219** destruction-order defect in the GrantleeTheme / MessageViewer /
QJSEngine path.
### Not confirmed
There is no evidence that Akonadi database corruption, MariaDB incompatibility,
IMAP/OAuth configuration, Btrfs quotas, disk capacity, NVMe media failure,
SELinux or OOM caused those crashes.
### Additional defects worth retaining from this supportconfig
Two findings should not be lost merely because the primary Kontact crash has an
upstream fix:
**Akonadi shutdown reliability**
```text
private mariadbd required SIGKILL after akonadi_control timeout
```
and:
**Akonadi/KDE PIM model lifecycle correctness**
```text
422 unmatched beginResetModel/endResetModel warnings
```
These should be treated as separate engineering work items.
### Highest-value openSUSE action
The most useful short-term Tumbleweed work is:
> **Ensure the KDE Bug 519219 fixes reach users, then use this system's
> subsequent behaviour as a regression check for both the Kontact teardown
> crash and the two secondary Akonadi issues.**
This supportconfig provides a particularly good pre-fix baseline because it
contains **two independent coredumps with the same fatal stack, repeated clean
Akonadi table checks, one separate Akonadi shutdown failure, and quantified
model-reset warnings**.
--
You are receiving this mail because:
You are watching all bug changes.
