|
Bugzilla – Full Text Bug Listing |
| Summary: | kwalletd constantly crashes after upgrade to openSUSE 15.6 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Vadim Krevs <vkrevs> |
| Component: | KDE Workspace (Plasma) | Assignee: | E-Mail List <opensuse-kde-bugs> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | fabian, fvogt, vkrevs |
| Version: | Leap 15.6 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | gdb stack trace from the core file | ||
|
Description
Vadim Krevs
2024-07-24 18:06:58 UTC
Created attachment 876244 [details]
gdb stack trace from the core file
Looks like it crashes on exit due to memory corruption. Do the crash timestamps line up with logouts? Please try qdbus-qt5 org.kde.kwalletd5 /MainApplication org.qtproject.Qt.QCoreApplication.exit then start kwalletd5 in valgrind: valgrind kwalletd5 When it started up, use kwalletmanager5 to confirm that it's working and use qdbus-qt5 org.kde.kwalletd5 /MainApplication org.qtproject.Qt.QCoreApplication.exit to cause it to exit. valgrind should have useful complaints. Hmm... $ qdbus-qt5 org.kde.kwalletd5 /MainApplication org.qtproject.Qt.QCoreApplication.exit Error: org.freedesktop.DBus.Error.UnknownMethod No such method 'exit' in interface 'org.qtproject.Qt.QCoreApplication' at object path '/MainApplication' (signature '') qdbus-qt5 org.kde.kwalletd5 /MainApplication org.qtproject.Qt.QCoreApplication.quit - this works. $ valgrind --tool=memcheck --num-callers=30 --leak-check=full --leak-resolution=med --trace-children=yes kwalletd5 ==3287== Memcheck, a memory error detector ==3287== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==3287== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==3287== Command: kwalletd5 ==3287== kf.wallet.kwalletd: Lacking a socket, pipe: 0 env: 0 ==3287== realloc() with size 0 ==3287== at 0x48489BC: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3287== by 0x16A0FC1F: ??? (in /usr/lib64/libnvidia-glcore.so.550.100) ==3287== by 0xE455986: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE4AF6D1: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE455012: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== Address 0xa463090 is 0 bytes after a block of size 0 alloc'd ==3287== at 0x4841744: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3287== by 0x16A0FC0F: ??? (in /usr/lib64/libnvidia-glcore.so.550.100) ==3287== by 0xE455986: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE4AF6D1: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE455012: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== ==3287== posix_memalign() invalid size value: 0 ==3287== at 0x4849127: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3287== by 0x16A0FC55: ??? (in /usr/lib64/libnvidia-glcore.so.550.100) ==3287== by 0xE455986: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE4AF6D1: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== by 0xE455012: ??? (in /usr/lib64/libGLX_nvidia.so.550.100) ==3287== ==3287== Conditional jump or move depends on uninitialised value(s) ==3287== at 0xE0F8B1C: ??? ==3287== by 0x1217ADD7: ??? ==3287== ==3287== Conditional jump or move depends on uninitialised value(s) ==3287== at 0xE0F8B1C: ??? ==3287== by 0x12053657: ??? ==3287== ==3287== Conditional jump or move depends on uninitialised value(s) ==3287== at 0xE0F8B1C: ??? ==3287== by 0x12053837: ??? ==3287== ==3287== ==3287== HEAP SUMMARY: ==3287== in use at exit: 366,268 bytes in 1,801 blocks ==3287== total heap usage: 417,462 allocs, 415,661 frees, 8,090,189,624 bytes allocated ==3287== ==3287== 1,687 (184 direct, 1,503 indirect) bytes in 1 blocks are definitely lost in loss record 357 of 382 ==3287== at 0x4848791: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3287== by 0x6FB65B4: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FBB55A: _dbus_message_loader_queue_messages (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FC406F: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FC4165: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FC4C9E: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FC5407: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FC3EBC: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FAC4BB: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FACE6C: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FAD42D: dbus_connection_send_with_reply_and_block (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FA929A: dbus_bus_register (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x6FA94CA: ??? (in /usr/lib64/libdbus-1.so.3.19.4) ==3287== by 0x16A79B0E: ??? ==3287== by 0x16A8C512: ??? ==3287== by 0x16A8CB07: ??? ==3287== by 0x16F7045C: ??? ==3287== by 0x16A17723: ??? ==3287== by 0x16A1F76A: ??? ==3287== by 0xE459143: ??? ==3287== by 0xE459287: ??? ==3287== by 0xE483F07: ??? ==3287== by 0xE478785: ??? ==3287== by 0x80B7B5B: ??? (in /usr/lib64/libGLX.so.0.0.0) ==3287== by 0xD9CBF65: ??? (in /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so) ==3287== by 0xD9C9426: ??? (in /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so) ==3287== by 0x8C52E0A: QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const (in /usr/lib64/libQt5XcbQpa.so.5.15.12) ==3287== by 0x5650CAE: QOpenGLContext::create() (in /usr/lib64/libQt5Gui.so.5.15.12) ==3287== by 0x8979CEF: ??? (in /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so) ==3287== by 0x60AD9A6: QCoreApplicationPrivate::init() (in /usr/lib64/libQt5Core.so.5.15.12) ==3287== ==3287== LEAK SUMMARY: ==3287== definitely lost: 184 bytes in 1 blocks ==3287== indirectly lost: 1,503 bytes in 2 blocks ==3287== possibly lost: 0 bytes in 0 blocks ==3287== still reachable: 362,565 bytes in 1,777 blocks ==3287== suppressed: 0 bytes in 0 blocks ==3287== Reachable blocks (those to which a pointer was found) are not shown. ==3287== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==3287== ==3287== Use --track-origins=yes to see where uninitialised values come from ==3287== For lists of detected and suppressed errors, rerun with: -s ==3287== ERROR SUMMARY: 8 errors from 6 contexts (suppressed: 0 from 0) Logging out does not seem to trigger the crash. That valgrind report looks harmless, no crash there. Unfortunately there's not much that can be done here until we get a proper valgrind report with a proper error. It would be helpful if you figure out a way to get it to crash more reliably. (In reply to Vadim Krevs from comment #6) > Logging out does not seem to trigger the crash. Actually, I was wrong. Almost every other logout triggers this crash. Curiously, another user account on the same machine can logout without dumping core. Logging into each user account auto-launches skype, which stores its password in the kwallet but logging out causes a crash only from one user account. I have attempted to rename kwalletd5 and replace it with a shell script that launches the renamed executable under valgrind passing all parameters, etc and redirecting output to a temp file. No more core files (as it usually happens when running things under valgrind obviously) and valgrind logs do not contain anything useful. Fabian - is there anything else you can think of to try to investigate this further? (In reply to Vadim Krevs from comment #8) > (In reply to Vadim Krevs from comment #6) > > Logging out does not seem to trigger the crash. > > Actually, I was wrong. Almost every other logout triggers this crash. > Curiously, another user account on the same machine can logout without > dumping core. Logging into each user account auto-launches skype, which > stores its password in the kwallet but logging out causes a crash only from > one user account. > > I have attempted to rename kwalletd5 and replace it with a shell script that > launches the renamed executable under valgrind passing all parameters, etc > and redirecting output to a temp file. No more core files (as it usually > happens when running things under valgrind obviously) and valgrind logs do > not contain anything useful. > > Fabian - is there anything else you can think of to try to investigate this > further? Not much. Do the various crashes have different backtraces? What the cause of a crash, is it a wild or null pointer? ("p *this" in gdb should show) (In reply to Fabian Vogt from comment #9) > (In reply to Vadim Krevs from comment #8) > > (In reply to Vadim Krevs from comment #6) > > > Logging out does not seem to trigger the crash. > > > > Actually, I was wrong. Almost every other logout triggers this crash. > > Curiously, another user account on the same machine can logout without > > dumping core. Logging into each user account auto-launches skype, which > > stores its password in the kwallet but logging out causes a crash only from > > one user account. > > > > I have attempted to rename kwalletd5 and replace it with a shell script that > > launches the renamed executable under valgrind passing all parameters, etc > > and redirecting output to a temp file. No more core files (as it usually > > happens when running things under valgrind obviously) and valgrind logs do > > not contain anything useful. > > > > Fabian - is there anything else you can think of to try to investigate this > > further? > > Not much. Do the various crashes have different backtraces? > > What the cause of a crash, is it a wild or null pointer? ("p *this" in gdb > should show) Same backtraces in all dumps. (gdb) where #0 0x00007f23b73e10a7 in QCA::Botan::MemoryRegion<unsigned char>::deallocate(unsigned char*, unsigned int) const (this=0x557c0c46a930, n=17, p=0x557c0c35a590 "") at /usr/src/debug/qca-qt5-2.3.9-lp156.33.1.x86_64/src/botantools/botan/botan/secmem.h:188 ... (gdb) p this $1 = (const QCA::Botan::MemoryRegion<unsigned char> * const) 0x557c0c46a930 (gdb) p *this $2 = {buf = 0x557c0c35a590 "", used = 17, allocated = 17, alloc = 0x557c0c4e1370} (gdb) (In reply to Vadim Krevs from comment #10) > (In reply to Fabian Vogt from comment #9) > > (In reply to Vadim Krevs from comment #8) > > > (In reply to Vadim Krevs from comment #6) > > > > Logging out does not seem to trigger the crash. > > > > > > Actually, I was wrong. Almost every other logout triggers this crash. > > > Curiously, another user account on the same machine can logout without > > > dumping core. Logging into each user account auto-launches skype, which > > > stores its password in the kwallet but logging out causes a crash only from > > > one user account. > > > > > > I have attempted to rename kwalletd5 and replace it with a shell script that > > > launches the renamed executable under valgrind passing all parameters, etc > > > and redirecting output to a temp file. No more core files (as it usually > > > happens when running things under valgrind obviously) and valgrind logs do > > > not contain anything useful. > > > > > > Fabian - is there anything else you can think of to try to investigate this > > > further? > > > > Not much. Do the various crashes have different backtraces? > > > > What the cause of a crash, is it a wild or null pointer? ("p *this" in gdb > > should show) > > Same backtraces in all dumps. > > (gdb) where > #0 0x00007f23b73e10a7 in QCA::Botan::MemoryRegion<unsigned > char>::deallocate(unsigned char*, unsigned int) const (this=0x557c0c46a930, > n=17, p=0x557c0c35a590 "") at > /usr/src/debug/qca-qt5-2.3.9-lp156.33.1.x86_64/src/botantools/botan/botan/ > secmem.h:188 > ... > (gdb) p this > $1 = (const QCA::Botan::MemoryRegion<unsigned char> * const) 0x557c0c46a930 > (gdb) p *this > $2 = {buf = 0x557c0c35a590 "", used = 17, allocated = 17, alloc = > 0x557c0c4e1370} > (gdb) What's *this->alloc in that case? Does it fault or return null or invalid pointers? (In reply to Fabian Vogt from comment #11) > (In reply to Vadim Krevs from comment #10) > > (In reply to Fabian Vogt from comment #9) > > > (In reply to Vadim Krevs from comment #8) > > > > (In reply to Vadim Krevs from comment #6) > > > > > Logging out does not seem to trigger the crash. > > > > > > > > Actually, I was wrong. Almost every other logout triggers this crash. > > > > Curiously, another user account on the same machine can logout without > > > > dumping core. Logging into each user account auto-launches skype, which > > > > stores its password in the kwallet but logging out causes a crash only from > > > > one user account. > > > > > > > > I have attempted to rename kwalletd5 and replace it with a shell script that > > > > launches the renamed executable under valgrind passing all parameters, etc > > > > and redirecting output to a temp file. No more core files (as it usually > > > > happens when running things under valgrind obviously) and valgrind logs do > > > > not contain anything useful. > > > > > > > > Fabian - is there anything else you can think of to try to investigate this > > > > further? > > > > > > Not much. Do the various crashes have different backtraces? > > > > > > What the cause of a crash, is it a wild or null pointer? ("p *this" in gdb > > > should show) > > > > Same backtraces in all dumps. > > > > (gdb) where > > #0 0x00007f23b73e10a7 in QCA::Botan::MemoryRegion<unsigned > > char>::deallocate(unsigned char*, unsigned int) const (this=0x557c0c46a930, > > n=17, p=0x557c0c35a590 "") at > > /usr/src/debug/qca-qt5-2.3.9-lp156.33.1.x86_64/src/botantools/botan/botan/ > > secmem.h:188 > > ... > > (gdb) p this > > $1 = (const QCA::Botan::MemoryRegion<unsigned char> * const) 0x557c0c46a930 > > (gdb) p *this > > $2 = {buf = 0x557c0c35a590 "", used = 17, allocated = 17, alloc = > > 0x557c0c4e1370} > > (gdb) > > What's *this->alloc in that case? Does it fault or return null or invalid > pointers? (gdb) p *this->alloc $4 = {_vptr.Allocator = 0x562bf278c} |