On Wed, 2024-12-04 at 09:55 +0100, Tomaz Canabrava wrote:
> Hello all, I have a quite annoying kmail crash, tried to debug but
> the codebase didn't help much.
> The crash happens in `kidentitymanager`, but I believe the culprit is
> in kmail itself.
> on KMail's `identitynpage.cpp`, method `slotRemoveIdentity` there are
> only two relevant calls:
>
> mIPage.mIdentityList->identityTreeModel()-
> >removeIdentities(listIdentityNames);
> save();
>
> That in turn calls kidentitymanager's KIdentityManager::commit(),
> the commit call fails here, on the iterator access.
>
> for (QList<Identity>::ConstIterator it = d-
> >shadowIdentities.constBegin();
> it != d->shadowIdentities.constEnd();
> ++it)
> {
> const int index = seenUOIDs.indexOf((*it).uoid());
>
> The crash is deep down inside QHash so for me this feels like memory
> corruption:
>
> Thread 1 "kmail" received signal SIGSEGV, Segmentation fault.
>
> QHash<QString, QVariant>::contains (this=0x555557a79a40, key=...) at
> /usr/include/qt6/QtCore/qhash.h:1015
>
> 1015 return d->findNode(key) != nullptr;
>
> (gdb) bt
>
> #0 QHash<QString, QVariant>::contains (this=0x555557a79a40, key=...)
> at /usr/include/qt6/QtCore/qhash.h:1015
>
> #1 KIdentityManagementCore::Identity::property
> (this=this@entry=0x555557a79a30, key=...)
>
> at
> /home/tcanabrava/Data/Projects/kde/src/kidentitymanagement/src/core/i
> dentity.cpp:286
>
> #2 0x00007fffe7923a10 in KIdentityManagementCore::Identity::uoid
> (this=this@entry=0x555557a79a30)
>
> at
> /home/tcanabrava/Data/Projects/kde/src/kidentitymanagement/src/core/i
> dentity.cpp:353
>
> #3 0x00007fffe7932961 in
> KIdentityManagementCore::IdentityManager::commit
>
>
> But all the memory we are directly acessing is in the stack.
> Note that the `contains` call doesn't exist on the current code, it
> was a try I did to make sure it wouldn't crash. the actuall code has
> a direct access to .value().
> but, well, it crashed anyway.
Just from the data here it seems like `d` is either `nullptr` or an
invalid pointer.
That said, if you think it's memory corruption, it may be useful to re-
build KMail with address sanitizer enabled and reproduce the problem.
It's output is usually very helpful in debugging that sort of issues.
---------
Another suggestion is to try using `_RR_TRACE_DIR=. rr record kmail` to
record KMail execution, reproduce the bug, and then just debug the
recorded version of the process (`_RR_TRACE_DIR=. rr replay`; I
personally added _RR_TRACE_DIR=. to my /etc/environment). `rr` is an
amazing tool for bugs where you're not sure where's the culprit,
because you can set a watchpoint on a variable, and use gdb's "reverse-
continue" (`rc`) command, and it will stop on the last location that
changed the variable.
Admittedly, I didn't try recording GUI apps wih `rr`, but `rr` was
initially developed by Mozilla folks for Firefox debugging (before `rr`
moved to its own project), so I think it should handle `KMail` fine.
Please note though that AFAIK `rr` launches GUI apps with software GPU
driver, because it doesn't handle DRM ioctls.
