| Summary: | NetworkManagement plasmoid causes kded4 crashes when activating network | ||
|---|---|---|---|
| Product: | [Unmaintained] Network Management | Reporter: | Raymond Wooninck <tittiatcoke> |
| Component: | KDED Module | Assignee: | Rick Stockton <rickstockton> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | kirelagin, lamarque, rickstockton, sven.burmeister |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Try to prevent crash
kded4 log with "Store connection secrets"="In secure storage" kded4 log with "Store connection secrets"="Do not store" Crash backtrace |
||
|
Description
Raymond Wooninck
2012-02-09 17:14:40 UTC
Created attachment 68712 [details]
Try to prevent crash
Please test the attached patch to see if it fix this problem.
Hi Lamarque, Unfortunately the patch didn't help. With the patch I receive the following crashlog: Application: KDE Daemon (kdeinit4), signal: Segmentation fault [Current thread is 1 (Thread 0x7f890ec82780 (LWP 3292))] Thread 2 (Thread 0x7f88eb484700 (LWP 3302)): #0 0x00007f8909190172 in g_main_context_query () from /usr/lib64/libglib-2.0.so.0 #1 0x00007f890919087a in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007f8909190a34 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007f890d8ef8e6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #4 0x00007f890d8bf682 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #5 0x00007f890d8bf8d7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #6 0x00007f890d7c04e7 in QThread::exec() () from /usr/lib64/libQtCore.so.4 #7 0x00007f890d89f48f in ?? () from /usr/lib64/libQtCore.so.4 #8 0x00007f890d7c350b in ?? () from /usr/lib64/libQtCore.so.4 #9 0x00007f890d52cdaa in start_thread () from /lib64/libpthread.so.0 #10 0x00007f890c28867d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f890ec82780 (LWP 3292)): [KCrash Handler] #6 ref (this=0x7f88ec0ff8b0) at ../../src/corelib/arch/qatomic_x86_64.h:121 #7 QExplicitlySharedDataPointer (o=..., this=0x7fff33159470) at ../../src/corelib/tools/qshareddata.h:169 #8 QDBusPendingCall::QDBusPendingCall (this=<optimized out>, other=<optimized out>) at qdbuspendingcall.cpp:253 #9 0x00007f88ebeb2d11 in NMDBusSettingsConnectionProvider::interfaceConnectionActivated (this=0xd1c400) at /sources/KDE-GIT/networkmanagement/backends/NetworkManager/nmdbussettingsconnectionprovider.cpp:297 #10 0x00007f890d8d4761 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/libQtCore.so.4 #11 0x00007f88ec336327 in Knm::Activatable::activate (this=0xcae920) at /sources/KDE-GIT/networkmanagement/libs/internals/activatable.cpp:80 #12 0x00007f88ec0ff92d in qt_static_metacall (_a=<optimized out>, _id=<optimized out>, _o=<optimized out>, _c=<optimized out>) at /sources/KDE-GIT/networkmanagement/build/libs/service/activatableadaptor.moc:92 #13 ActivatableAdaptor::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /sources/KDE-GIT/networkmanagement/build/libs/service/activatableadaptor.moc:81 #14 0x00007f88ec0ffa77 in ActivatableAdaptor::qt_metacall (this=0xd39d60, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0x7fff33159840) at /sources/KDE-GIT/networkmanagement/build/libs/service/activatableadaptor.moc:135 #15 0x00007f890a5d5f6b in QDBusConnectionPrivate::deliverCall (this=0x6aab90, object=0xd39d60, msg=..., metaTypes=..., slotIdx=8) at qdbusintegrator.cpp:947 #16 0x00007f890a5d707d in QDBusConnectionPrivate::activateCall (this=0x6aab90, object=0xd39d60, flags=273, msg=...) at qdbusintegrator.cpp:850 #17 0x00007f890a5d7a9b in QDBusConnectionPrivate::activateObject (this=0x6aab90, node=..., msg=..., pathStartPos=<optimized out>) at qdbusintegrator.cpp:1423 #18 0x00007f890a5d7b8b in QDBusActivateObjectEvent::placeMetaCall (this=0xca54a0) at qdbusintegrator.cpp:1537 #19 0x00007f890d8d9926 in QObject::event(QEvent*) () from /usr/lib64/libQtCore.so.4 #20 0x00007f890ca29ee4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #21 0x00007f890ca2ed63 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4 #22 0x00007f890e67f816 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/libkdeui.so.5 #23 0x00007f890d8c089c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4 #24 0x00007f890d8c413a in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQtCore.so.4 #25 0x00007f890d8ef453 in ?? () from /usr/lib64/libQtCore.so.4 #26 0x00007f89091905aa in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #27 0x00007f8909190970 in ?? () from /usr/lib64/libglib-2.0.so.0 #28 0x00007f8909190a34 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #29 0x00007f890d8ef87f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #30 0x00007f890cacd33e in ?? () from /usr/lib64/libQtGui.so.4 #31 0x00007f890d8bf682 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #32 0x00007f890d8bf8d7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4 #33 0x00007f890d8c4435 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4 #34 0x00007f88fbcaa495 in kdemain () from /usr/lib64/libkdeinit4_kded4.so #35 0x00000000004089e4 in _start () Any new patch to try? No. I really do not know why Qt 4.8 is doing this. symptoms imply that behavior changed _within_ Qt (between 4.7 and 4.8.0, which is supposed to have been a backward compatible upgrade.) This will probably end up with escalation into Qt.... But I'll need to do further isolation over the weekend. (GIT "blame" and etc.) I am not able to reproduce this problem in a Mer image running in VirtualBox. I am running Qt 4.8.0, NetworkManager 0.9.4, Plasma NM master and QtNetworkManager master (AKA libnm-qt) from March 9 and it does not crash here whe I activate an user wired connection using Plasma NM. Latest update: When running this with Qt 4.8.1 everything works as expected and there are no more crashes. I guess that 4.8.1 resolved it. Lamarque, I noticed that your tried with activating a wired connection. As that with me clicking the network cable, automatically sets a connection, I only used wireless connections to test it with and there it used to fail. So I am not sure if the wireless is activated differently, but as indicated the bug is no longer there. Strange, I am using Qt 4.8.0 here and it works. I used wired connection but I disable the autoconnect feature and make it user connection instead of system. Wired, wireless and all other connections (except VPN) are activated the same way. Guys, I no longer have the problem either. Raymond did great work in reporting this bug; it almost certainly IS a defect in NetworkManager code (hereafter "NM"), exposed by KDE 4.8.x in conjuction with Qt. NM behavior was still defective on my 3-/23 "Alpha" F17 Build, but I forgot to check the the level of NM which was included there. When I rebuilt my system last night, using F17's "Beta RC3" installer (just a few hours after they put it up on the FTP Servers, NM works) -- from within both Gnome and KDE, I founc that NM (the core) is included at a patch level described as "0.9.4.0-1git20120328.fc17". There have been several very recent fixes involving uninitiailzed NM object references, and one of them almost certainly eliminated our exposure to the problem within Qt 4.8.x. But, rather than mark the resolution as WORKSFORME, I'm changin to to UPSTREAM... because updating NM definitely provided the repair in my own case. (Fedora-17-pre.) Raymond, can you confirm that OpenSuse-12 pre-Release now works? If you're wiling to experiment, at the risk of system SW breakage, it would probably be new enough within nightly "testing" Repos. If you're using OpenSuse on Production, and want to wait for the next fully-tested Milestone, feel free to report back later. I'll assume that it's fixed via updated Gentoo Linux amd64 Qt 4.8.1, NetworkManager 0.9.4.0, 0.9.0.2 kded4 crashes when I try to add networkmanagement applet (or when logging in). After this I get old colorful icons in statusbar and networkmanagement seems to be working fine (ok, not fine, but this seems to be my own problem with NM and my wifi card). This happens even if the NM is not started, so I don't think this bug could be fixed upstream. I use almost the same specs (Gentoo, Qt 4.8.1, Plasma NM 0.9.0.2, NetworkManager 0.9.2.0) and do not have any crashes here. Send me the crashlog. I haven't managed to get a crashlog. kdelibs package is built with USE="debug" and FEATURES="splitdebug compressdebug", so gdb is able to find symbols, but drkonqi gives a useless backtrace. I also can't find a way to get this t by running kded4 with gdb manually—it escapes from gdb.I'm not that good at debugging kde programs =(. Hope you can tell me what to d to get a good bt. But what's clear is that the problem is somehow related to KWallet. When I disable storing of connection secrets everything works fine. (I'll add some logs) One more thing. I'm running kde (and kwallet) 4.8.3. Created attachment 71190 [details]
kded4 log with "Store connection secrets"="In secure storage"
I don't get what's going on with utempter…
Created attachment 71191 [details]
kded4 log with "Store connection secrets"="Do not store"
Seems to work fine.
Use "kded4 --nocrashhandler --nofork" to run it through gdb. Please also run it through valgrind, which generates a log with more details than gdb. Since the problem only happens when using kwallet your problem may be related to https://bugs.kde.org/show_bug.cgi?id=283105. Created attachment 71220 [details]
Crash backtrace
Ok, I've managed to get a meaningful bt.
I've never used valgrind before, but if you believe it is useful here, I'll try to make a bt with valgrind.
(In reply to comment #16) > Created attachment 71220 [details] > Crash backtrace > > Ok, I've managed to get a meaningful bt. Yeah, it contains some usefull information. Your bug is https://bugs.kde.org/show_bug.cgi?id=300113, not this one. This one happens when the Solid backend is trying to retrieve NetworkManager's current state. Your bug happens when trying to import old NM-0.8 connections. > I've never used valgrind before, but if you believe it is useful here, I'll > try to make a bt with valgrind. Yes, do it. I cannot reproduce this bug here. Please, add the valgrind log to bug #300113 Oops, I've removed ~/.kde4/share/apps/networkmanagement/connections and I'm afraid I've accidentally lost backups of those files, so now I can't reproduce the bug. I'm really sorry =(. |