| Summary: | Plasma keeps crashing | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Hans Brage <hans> |
| Component: | generic-crash | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | crash | CC: | akontsevich, fabian, jirislaby, kde, kde, nate, qydwhotmail |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.27.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| URL: | https://bugzilla.suse.com/show_bug.cgi?id=1208188 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
attachment-2084109-0.html
valgrind of plasmashell |
||
|
Description
Hans Brage
2023-02-16 21:42:40 UTC
Try to delete ~/.cache folder and test again Tried to remove ~/.cache (renamed it) and then rebooted the system. Folder is recreated but plasma still crasches. Den 2023-02-17 kl. 02:02, skrev Fushan Wen: > https://bugs.kde.org/show_bug.cgi?id=465872 > > Fushan Wen <qydwhotmail@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |qydwhotmail@gmail.com > > --- Comment #1 from Fushan Wen <qydwhotmail@gmail.com> --- > Try to delete ~/.cache folder and test again > Does it crash right after it is started? Randomly during execution? Or when you do something specifc? Created attachment 156356 [details] attachment-2084109-0.html It crashes shortly after login. I can see that background and desktop icons briefly appears and disappears. Then is the crash window displayed for some second and I looks like also that application crashes as the window disappears. Then it looks like it tries to restart itself as I can see objects on desktop occasionally flashing and also some crash windows flashing by. /var/log/messages also fills up with repeated entries. To be able to send the report I used the killall and a manual start of plasma. Den 17 februari 2023 09:30:05 skrev "David Redondo" <bugzilla_noreply@kde.org>: > https://bugs.kde.org/show_bug.cgi?id=465872 > > David Redondo <kde@david-redondo.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kde@david-redondo.de > > --- Comment #3 from David Redondo <kde@david-redondo.de> --- > Does it crash right after it is started? Randomly during execution? Or when you > do something specifc? > > -- > You are receiving this mail because: > You reported the bug. I have the same bug after recent openSUSE Tubleweed upgrades: Plasmashell constantly freezes (100% CPU) and crashes. Please file a new bug report for that, as there's no way to know it's the same issue without a backtrace of the crash. (In reply to Nate Graham from comment #6) > Please file a new bug report for that, as there's no way to know it's the > same issue without a backtrace of the crash. Same OS, same kernel, same plasma version, same symptoms, same time! What else?! I reported the bug but kde crash reporter had not uploaded it for some reason - also buggy! ;) I did kill plasmashell, then deleted ~/.cache, then restarted plasmashell - no freezes observed since then. Will check more tomorrow. If you can reproduce it, please get a backtrace and file a new bug report. (In reply to Nate Graham from comment #8) > If you can reproduce it, please get a backtrace and file a new bug report. After cache cleaning it sometimes crashes but now it restarts immediately after the crash so it is less annoying. However crash reporter does not appear now, so I can't report the stack. (In reply to Aleksey Kontsevich from comment #9) > (In reply to Nate Graham from comment #8) > > If you can reproduce it, please get a backtrace and file a new bug report. > > After cache cleaning it sometimes crashes but now it restarts immediately > after the crash so it is less annoying. However crash reporter does not > appear now, so I can't report the stack. Crashes again, workaround helped temporarily. Now it freezes all the time!!! Every minute!!! 100% CPU load - killing and restart does not help!!! Do something! I already told you what you need to do, Aleksey: get a backtrace and submit a new bug report with it, as there is no indication that your issue is the same as this one. (In reply to Nate Graham from comment #12) > I already told you what you need to do, I already told You that I can't! >Aleksey: get a backtrace and submit HOW???!!! Crash reporter does not appear! > there is no indication that your issue is the same as this one. There are a lot of indications the issues is the same: - Same OS - openSUSE Tumbleweed - same kernel version - same plasma version - same symptoms - same time it appeared - same OS upgrade in Tumbleweed !!!! See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl to get a backtrace of the crash without the wizard appearing. Please don't add any new comments to this bug report. > coredumpctl
No coredumps found.
Tried gdb however it does not allow to catch these freezes - only crashes, no crash yet however. However found condition when it always crashes/freezes: press Klipper hotkey - to show records at mouse position, switch to cyrillic, type something - to filter records - crash/freeze. Ha, appeared drkonqi created the bug reports already: - https://bugs.kde.org/show_bug.cgi?id=465962 - https://bugs.kde.org/show_bug.cgi?id=466236 The latter with debug symbols. For me, it works until I update (only) this: glibc 2.36-9.2 -> 2.37-1.4 glibc-devel 2.36-9.2 -> 2.37-1.4 glibc-extra 2.36-9.2 -> 2.37-1.4 glibc-locale 2.36-9.2 -> 2.37-1.4 glibc-locale-base 2.36-9.2 -> 2.37-1.4 Created attachment 156860 [details] valgrind of plasmashell > Invalid read of size 4 > at 0x5686376: UnknownInlinedFun (qqmljavascriptexpression_p.h:230) > by 0x5686376: QQmlPropertyCapture::captureProperty(QObject*, int, int, bool) (qqmljavascriptexpression.cpp:281) > by 0x831975B: QV4::ModelObject::virtualGet(QV4::Managed const*, QV4::PropertyKey, QV4::Value const*, bool*) (qqmllistmodel.cpp:1639) > by 0x551C680: UnknownInlinedFun (qv4object_p.h:308) > by 0x551C680: QV4::Lookup::getterFallback(QV4::Lookup*, QV4::ExecutionEngine*, QV4::Value const&) (qv4lookup.cpp:231) > by 0x8314B38: QV4::ModelObject::virtualResolveLookupGetter(QV4::Object const*, QV4::ExecutionEngine*, QV4::Lookup*) (qqmllistmodel.cpp:1650) > by 0x551D78D: QV4::Lookup::getterGeneric(QV4::Lookup*, QV4::ExecutionEngine*, QV4::Value const&) (qv4lookup.cpp:144) > by 0x558F20B: QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) (qv4vme_moth.cpp:641) > by 0x5592E3B: UnknownInlinedFun (qv4vme_moth.cpp:466) > by 0x5592E3B: QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (qv4vme_moth.cpp:430) > by 0x553DCFD: QV4::ArrowFunction::virtualCall(QV4::FunctionObject const*, QV4::Value const*, QV4::Value const*, int) (qv4functionobject.cpp:528) > by 0x55A43E9: UnknownInlinedFun (qv4functionobject_p.h:202) > by 0x55A43E9: QV4::Runtime::CallQmlContextPropertyLookup::call(QV4::ExecutionEngine*, unsigned int, QV4::Value*, int) (qv4runtime.cpp:1366) > by 0x5590E13: QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) (qv4vme_moth.cpp:787) > by 0x5592E3B: UnknownInlinedFun (qv4vme_moth.cpp:466) > by 0x5592E3B: QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (qv4vme_moth.cpp:430) > by 0x553DCFD: QV4::ArrowFunction::virtualCall(QV4::FunctionObject const*, QV4::Value const*, QV4::Value const*, int) (qv4functionobject.cpp:528) > Address 0x8dc35e63 is not stack'd, malloc'd or (recently) free'd So it's apparently not even use after free. (In reply to Hans Brage from comment #0) > #7 0xb442e75c in QV4::ModelObject::virtualGet(QV4::Managed const*, > QV4::PropertyKey, QV4::Value const*, bool*) (m=0xa15c0820, id=..., > receiver=0xa15c0820, hasProperty=0x0) at > /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qmlmodels/ > qqmllistmodel.cpp:1639 ep is corrupted: 1639 if (QQmlEngine *qmlEngine = that->engine()->qmlEngine()) { 1640 QQmlEnginePrivate *ep = QQmlEnginePrivate::get(qmlEngine); 1641 if (ep && ep->propertyCapture) { 1642 qDebug() << __func__ << ep << ep->propertyCapture; 1643 ep->propertyCapture->captureProperty(that->object(), -1, role->index, /*doNotify=*/ false); 1644 } 1645 } This prints: virtualGet 0xb706dff0 0x8dc35e5b So: > (gdb) p *(QQmlEnginePrivate *)0xb706dff0 > $3 = {<QJSEnginePrivate> = {<QObjectPrivate> = {<QObjectData> = {_vptr.QObjectData = 0x39e85356, q_ptr = 0x81ffe0f8, parent = 0x1a1265c3, children = {<QListSpecialMethods<QObject*>> = {<No data fields>}, {p = { > static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x4ec8300}, d = 0x4ec8300}}, isWidget = 1, blockSig = 1, wasDeleted = 0, > isDeletingChildren = 1, sendChildEvents = 0, receiveChildEvents = 0, isWindow = 0, deleteLaterCalled = 1, unused = 1320052, postedEvents = 1081407109, metaObject = 0x8d08ec83}, extraData = 0xed9c9483, > threadData = {<QBasicAtomicPointer<QThreadData>> = {_q_value = std::atomic<QThreadData *> = { 0xe85650ff }}, <No data fields>}, connections = {<QBasicAtomicPointer<QObjectPrivate::ConnectionData>> = { > _q_value = std::atomic<QObjectPrivate::ConnectionData *> = { 0xffe076c8 }}, <No data fields>}, {currentChildBeingDeleted = 0x8910c483, declarativeData = 0x8910c483}, > sharedRefcount = {<QBasicAtomicPointer<QtSharedPointer::ExternalRefCountData>> = {_q_value = std::atomic<QtSharedPointer::ExternalRefCountData *> = { 0x24448bc2 }}, <No data fields>}}, > mutex = {<QMutex> = {<QBasicMutex> = {d_ptr = {_q_value = std::atomic<QMutexData *> = { 0x75d28510 }}}, <No data fields>}, <No data fields>}, uiLanguage = {d = 0x4c4830b}}, > static baseModulesUninitialized = false, propertyCapture = 0x8dc35e5b, jsExpressionGuardPool = {d = 0x90002674}, rootContext = 0x5608ec83, profiler = 0x5756e850, outputWarningsToMsgLog = 224, cleanup = 0x4c48310, > erroredBindings = 0x8dc35e5b, inProgressCreations = -1879038348, workerScriptEngine = 0xd9ebc031, baseUrl = {d = 0x26748d}, activeObjectCreator = 0x53565755, networkAccessManager = 0xe0f7d7e8, > networkAccessManagerFactory = 0x3c381ff, imageProviders = {{d = 0x83001a12, e = 0x83001a12}}, urlInterceptor = 0x748b0cec, scarceResourcesRefCount = 2089493540, importDatabase = { > qmldirCache = {<QStringHashBase> = {<No data fields>}, data = {buckets = 0xf6852024, numBuckets = -326927756, size = 1417907464, numBits = -4460}, newedNodes = 0xe85650fd, nodePool = 0xffe07660}, > filePluginPath = {<QList<QString>> = {<QListSpecialMethods<QString>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, > array = {0x0}}, d = 0x8510c483}, d = 0x8510c483}}, <No data fields>}, fileImportPath = {<QList<QString>> = {<QListSpecialMethods<QString>> = {<No data fields>}, {p = {static shared_null = {ref = { > atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x833174c0}, d = 0x833174c0}}, <No data fields>}, qmlDirFilesForWhichPluginsHaveBeenLoaded = { > q_hash = {{d = 0x838d08ec, e = 0x838d08ec}}}, initializedPlugins = {q_hash = {{d = 0xffeee270, e = 0xffeee270}}}, engine = 0x49e85650}, typeLoader = {m_engine = 0x83ffe076, m_thread = 0xc08510c4, > m_mutex = @0xec831774, m_profiler = {d = 0x94838d08}, m_networkReplies = {{d = 0x50ffeee2, e = 0x50ffeee2}}, m_typeCache = {{d = 0x7632e856, e = 0x7632e856}}, m_typeCacheTrimThreshold = -997982240, > m_scriptCache = {{d = 0x75c08510, e = 0x75c08510}}, m_qmldirCache = {{d = 0x86f8d13, e = 0x86f8d13}}, m_importDirCache = {f = 0x890cc483, l = 0x5f5e5be8, hash = {{ > d = 0xb68dc35d <QMenuBar::mousePressEvent(QMouseEvent*)+29>, e = 0xb68dc35d <QMenuBar::mousePressEvent(QMouseEvent*)+29>}}, mx = 0, total = 1443425411}, > m_importQmlDirCache = {<QStringHashBase> = {<No data fields>}, data = {buckets = 0x56bee857, numBuckets = -997982240, size = 214205200, numBits = -14967}, newedNodes = 0x5d5f5ee8, nodePool = 0x26b48dc3}}, > offlineStoragePath = {d = 0x0}, uniqueId = 3438013745, incubatorList = {__first = 0x26748d}, incubatorCount = 69485707, incubationController = 0x30440c7, static qml_debugging_enabled = false, > networkAccessManagerMutex = {<QBasicMutex> = {d_ptr = {_q_value = std::atomic<QMutexData *> = { 0xc3000000 }}}, <No data fields>}, singletonInstances = {{d = 0x26748d, e = 0x26748d}}, cachedValueTypeInstances = {{ > d = 0x89565755, e = 0x89565755}}, m_compositeTypes = {{d = 0x25e853c6, e = 0x25e853c6}}, static s_designerMode = false, toDeleteInEngineThread = {_first = 0x81ffe0f7, _last = 0x1a1151c3, _flag = 0, > _count = 376848768}} Many values/pointers are 0x8dc35e5b or -1879038348/0x90002674 or 0xc483ffe0/-997982240 or their combination. That is obviously bogus. (In reply to Jiri Slaby from comment #21) > ep is corrupted: > 1639 if (QQmlEngine *qmlEngine = that->engine()->qmlEngine()) { > 1640 QQmlEnginePrivate *ep = QQmlEnginePrivate::get(qmlEngine); > 1641 if (ep && ep->propertyCapture) { > 1642 qDebug() << __func__ << ep << ep->propertyCapture; > 1643 ep->propertyCapture->captureProperty(that->object(), -1, > role->index, /*doNotify=*/ false); > 1644 } > 1645 } > > This prints: > virtualGet 0xb706dff0 0x8dc35e5b ... > Many values/pointers are 0x8dc35e5b or -1879038348/0x90002674 or > 0xc483ffe0/-997982240 or their combination. That is obviously bogus. Ah, because it's not ep at that location -- 0xb706dff0 is code, not data: > (gdb) x/24x 0xb706dff0 > 0xb706dff0 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc>: 0x39e85356 0x81ffe0f8 0x1a1265c3 0x04ec8300 > 0xb706e000 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc+16>: 0x1424748b 0x4074f685 0x8d08ec83 0xed9c9483 > 0xb706e010 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc+32>: 0xe85650ff 0xffe076c8 0x8910c483 0x24448bc2 > 0xb706e020 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc+48>: 0x75d28510 0x04c4830b 0x8dc35e5b 0x90002674 > 0xb706e030 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc+64>: 0x5608ec83 0x5756e850 0xc483ffe0 0x04c48310 > 0xb706e040 <_ZN20QQmlDelayedCallQueue11qt_metacastEPKc+80>: 0x8dc35e5b 0x90002674 0xd9ebc031 0x0026748d (In reply to Jiri Slaby from comment #22) > Ah, because it's not ep at that location -- 0xb706dff0 is code, not data: So: ================ ExecutionEngine::setQmlEngine(this=0xb59250) sets m_qmlEngine to 0xb7b73c <no other setQmlEngine() here> virtualGet that=0x9fbc0820 eng=0xb59250 qeng=0xb7208f08 I.e. ExecutionEngine is created by new(), 0xb7b73c is set as m_qmlEngine. Nothing else sets m_qmlEngine during runtime and then it crashes. At that point, the engine is still the one created earlier (0xb59250), but its m_qmlEngine is suddenly 0xb7208f08 (a pointer to the code). This really looks like a memory corruption. Note that when I set up a breakpoint in ExecutionEngine::setQmlEngine, the issue doesn't occur. So it is likely racy on the top of the above. (I wanted to add a "watch" to ExecutionEngine::m_qmlEngine there to see who overwrites that. Maybe we should continue in downstream (openSUSE miscompilation) or upstream (qt bug). (In reply to Jiri Slaby from comment #23) > (In reply to Jiri Slaby from comment #22) > > Ah, because it's not ep at that location -- 0xb706dff0 is code, not data: > > So: > ================ ExecutionEngine::setQmlEngine(this=0xb59250) sets > m_qmlEngine to 0xb7b73c > <no other setQmlEngine() here> > virtualGet that=0x9fbc0820 > eng=0xb59250 > qeng=0xb7208f08 > > I.e. ExecutionEngine is created by new(), 0xb7b73c is set as m_qmlEngine. > Nothing else sets m_qmlEngine during runtime and then it crashes. At that > point, the engine is still the one created earlier (0xb59250), but its > m_qmlEngine is suddenly 0xb7208f08 (a pointer to the code). This really > looks like a memory corruption. > > Note that when I set up a breakpoint in ExecutionEngine::setQmlEngine, the > issue doesn't occur. So it is likely racy on the top of the above. (I wanted > to add a "watch" to ExecutionEngine::m_qmlEngine there to see who overwrites > that. > > Maybe we should continue in downstream (openSUSE miscompilation) or upstream > (qt bug). Can you try a hardware watchpoint on that location before the corruption happens, i.e. `watch -l m_qmlEngine`? (In reply to Jiri Slaby from comment #23) > Maybe we should continue in downstream (openSUSE miscompilation) or upstream > (qt bug). Resolved downstream by dropping non-sse2 builds of qt libraries (which are apparently broken), see the downstream bug. https://bugzilla.suse.com/show_bug.cgi?id=1208188 (In reply to Jiri Slaby from comment #25) > (In reply to Jiri Slaby from comment #23) > > Maybe we should continue in downstream (openSUSE miscompilation) or upstream > > (qt bug). > > Resolved downstream by dropping non-sse2 builds of qt libraries (which are > apparently broken), see the downstream bug. > https://bugzilla.suse.com/show_bug.cgi?id=1208188 They said it is a different bug! https://bugzilla.suse.com/show_bug.cgi?id=1208188#c12 This bug report is specific to 32bit x86. If you see something on x86_64, that's a different bug. Please do not reopen this bug. (In reply to Fabian Vogt from comment #27) > This bug report is specific to 32bit x86. If you see something on x86_64, > that's a different bug. > > Please do not reopen this bug. Ah sorry, not mine, mine is: https://bugs.kde.org/show_bug.cgi?id=466236 |