Summary: | kde-base/plasma-workspace-4.3.0 crashes on startup | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kevin Lyons <hamburglar6> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arekm, artjom.simon, caster, daggs, ganellon, hamburglar6, Hugo.Mildenberger, kamil, svenne |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 297221 | ||
Bug Blocks: | |||
Attachments: |
plasma-workspace backtrace
kde daemon crash backtrace |
Description
Kevin Lyons
2009-08-19 04:31:42 UTC
might be gcc-4.4.1 related. I had similar problems with 4.4.0 and 4.4.1, but after reinstalling kde with gcc-4.3.4 they were gone. Could you please provide a backtrace from this crash? (In reply to comment #1) > might be gcc-4.4.1 related. > > I had similar problems with 4.4.0 and 4.4.1, but after reinstalling kde with > gcc-4.3.4 they were gone. > > Could you please provide a backtrace from this crash? > drkonqi is crashing when I try to save the backtrace, and says the backtrace info wasn't useful anyways. Is there some other way to get at the backtrace besides saving it through drkonqi? Also, I didn't originally compile kde with ggdb in my CFLAGS and splitdebug in my FEATURES in make.conf. I put them in and recompiled plasma-workspace, but this didn't improve the quality of the backtrace. Do I need to recompile something (or everything) else to get a useful backtrace? I did an emerge -eav world with gcc-4.3.4 overnight and that didn't fix the bug. Everything on my system is compiled to get useful backtrace info now, and drkonqi is getting meaningful backtraces from the crashes- whenever I try to save the backtrace file however drkonqi crashes. If there is some way to do it myself through gdb I could post the info here. I tried $gdb /usr/bin/startx, but it turns out that doesn't work and I'm a dunce. (In reply to comment #3) > If there is some way to do it myself through gdb I could post the info here. If you add the following 2 lines to ~/.kde4/share/config/drkonqirc, you will see a new button, "Debug", on the DrKonqi screen. If you click that button, then choose the option to open gdb, it will open a gdb session in a new Konsole, where you can get the backtrace yourself. Add these two lines to ~/.kde4/share/config/drkonqirc: [drkonqi] ShowDebugButton=true Thanks a lot Jonathan, that did the trick. plamsa-workspace crashes first, and then that is followed by the kde daemon crashing. I'm attaching the backtraces from both. (In reply to comment #4) > (In reply to comment #3) > > If there is some way to do it myself through gdb I could post the info here. > > If you add the following 2 lines to ~/.kde4/share/config/drkonqirc, you will > see a new button, "Debug", on the DrKonqi screen. If you click that button, > then choose the option to open gdb, it will open a gdb session in a new > Konsole, where you can get the backtrace yourself. > > Add these two lines to ~/.kde4/share/config/drkonqirc: > > [drkonqi] > ShowDebugButton=true > Created attachment 201989 [details]
plasma-workspace backtrace
Created attachment 201991 [details]
kde daemon crash backtrace
I think I have the same thing but it is more random and varies in times I got the same problem after upgrading to KDE 4.3.0. I alo have gcc-4.4.1. Already tried recompiling kdelibs and plasma-workspace, different or no CFLAGS/LDFLAGS at all, and moving my .kde4 directory away. Nothing helped. Can't start kde-4.3. Any ideas? Ok, i got mine fixed by re-merging the new jpeg-7. Apparently, this solved it. Had a few gtk-related problems solved, too after remerging. Hope that helps everyone. Re-emerging jpeg-7 didn't fix the problem here. (In reply to comment #10) > Ok, i got mine fixed by re-merging the new jpeg-7. > Apparently, this solved it. Had a few gtk-related problems solved, too after > remerging. > > Hope that helps everyone. > haven't noticed any crash yet but upgrading broke my entire system almost Upgrading to kde 4.3.1 didn't fix the bug. Also submitted upstream just now- http://bugs.kde.org/show_bug.cgi?id=206076 A few things to try: make sure dbus and hald are started. consolekit and policykit too if you have them enabled. try disabling composite by adding the following in your xorg.conf: Section "Extensions" Option "Composite" "true" EndSection Thanks :) (In reply to comment #15) > try disabling composite by adding the following in your xorg.conf: > Section "Extensions" > Option "Composite" "true" > EndSection c/p fail :p that should be "false" :) Section "Extensions" Option "Composite" "false" EndSection Another interesting option that seems to work for some people is to rebuild qt-gui. Please try that as well: emerge -av1 qt-gui hald, dbus, and consolekit are all in my default runlevel and start on boot. I wasn't using policykit before, but added it to my make.conf and did an emerge -uND to see if that changed anything, and it didn't. There isn't an init script in /etc/init.d/ for policykit...is there some way it needs to be started that I'm missing? Likewise recompiling qt-gui, then kdelibs and PyQt4 didn't fix it, or disabling compositing in xorg.conf. In the upstream bug I was directed to try $kbuildyscoca4 --noincremental and I get the following error: $ kbuildsycoca4 --noincremental kbuildsycoca4 running... kbuildsycoca4: ERROR creating database '/var/tmp/kdecache-kevin/ksycoca4'! Unable to open temporary file. QFile::remove: Empty or null file name I checked and only root has write privileges for /var/tmp/kdecache-kevin/ksycoca4. Did I do something stupid somewhere, is this a Gentoo problem, or an upstream problem? OK, problem solved (for me at least). The permissions of the entire folder /var/tmp/kdecache-$USER/ only allowed root write access. After changing the permissions to allow normal user access, and running $kbuildyscoca4 --noincremental, KDE is back up and running. I have no idea why the permissions of the folder were messed up, I have never ventured into /var/tmp/ before tonight. I'll leave it to more capable hands to decide whether or not to close the bug, in case this is a problem with one of the kde ebuilds somewhere (or if there is some good reason I should not have enabled user access to that directory). sudo could cause problems like this, creating _user_ files with wrong (root) permissions. did you ever run anything like sudo kbuildsycoca4? or sudo startx? In any case, its good to know what the cause was. It should go to our KDE 4 guide so I'm gonna leave the bug open until we get it documented. I think that what was messed up is the owner of the directory, is suppose to be $USER, not root I don't even have sudo installed on my machine right now, so it couldn't have been that. I have used startx as root, but that should have only created files for root and not affected other users files unless my understanding is incorrect. (In reply to comment #20) > sudo could cause problems like this, creating _user_ files with wrong (root) > permissions. did you ever run anything like sudo kbuildsycoca4? or sudo startx? > > In any case, its good to know what the cause was. It should go to our KDE 4 > guide so I'm gonna leave the bug open until we get it documented. > I have masked latest version of hal(sys-apps/hal-0.5.14), emerged previous version of it and after restarting hald, plasma workspace was up and running It seems that the problem is in latest hal(sys-apps/hal-0.5.14). After masking it and emerging previous version and restarting hald, plasma-workspace is up and running (In reply to comment #24) > It seems that the problem is in latest hal(sys-apps/hal-0.5.14). > After masking it and emerging previous version and restarting hald, > plasma-workspace is up and running > running 4.3.4 and latest hal, plasma-workspace is stable. maybe on 4.3.0 it is related but not in 4.3.4 my system also has this problem with HAL 0.5.14 .. everything works fine with HAL 0.5.13-r2 Hi, I have kde-base/plasma-workspace-4.3.4 and it's crashing with HAL 0.5.14. It's the first time that I have that kind of crash since KDE 4.2.x. So I think that the bug is related with the latest version of HAL because of the downgrade of HAL, everything is working again. I have the consolekit use flag but I don't start the service. I can confirm as well, downgrading hal to 0.5.13-r2 fix the segfault for me too. And, this is the only thing i did after i've update my whole system (kde 4.3.4, qt 4.6, and many more) to fix this bug. Confirmed problem with hal. Thanks guys, you just saved my ass. I hit the same behaviour after updating to kde-4.3.4, using sys-apps/hal-0.5.14 and sys-devel/gcc-4.3.4. From what I've seen from comment #14, there seem be different reasons leading to the same behavior. This is what happened on hardened ~x86: 0 QVariant::toDouble (this=0x0, ok=0x0) at kernel/qvariant.cpp:2361 1 0x3eaf13b1 in HalPower::brightness (this=0x14967798, device=@0x14a613dc) at /usr/src/debug/ kde-base/solid-4.3.4/solid-4.3.4/solid/hal/halpower.cpp:396 2 0x3ed64b21 in Solid::Control::PowerManager::brightness (device=@0x59b8fe68) at /usr/src/debug/ kde-base/solid-4.3.4/solid-4.3.4/libs/solid/control/powermanager.cpp:198 The reason was (in my case), that line 396 brightness = deviceInterface.call("GetBrightness").arguments().at(0).toDouble(); of solid/hal/halpower.cpp tried to use a NULL reference as a QVariant instance. Here is a temporary workaround, tested with kde-base/solid-4.3.4-r1 --- solid/hal/halpower.cpp.old 2009-12-12 19:51:15.000000000 +0100 +++ solid/hal/halpower.cpp 2009-12-12 20:08:18.000000000 +0100 @@ -442,6 +442,7 @@ } } +#if 0 reply = m_halManager.call("FindDeviceByCapability", "keyboard_backlight"); if(reply.isValid() && reply.value().contains(device)) { @@ -455,6 +456,7 @@ return true; } } +#endif return false; } I had the same problem: even removing my KDE profile (.kde4) my plasma-desktop kept crashing. Like one of the other posters I found one of the dbus calls crashing. Masking hal-0.5.14 solved that problem, however, restoring my profile crashed the desktop again. I found out that networkmanager-0.7.2 seems to be the cause since adding the networkmanager applet to plasma insta-crashed it in a fresh profile. Also cnetworkmanager does not work. Reverting to 0.7.1 fixed that problem as well. Should I create a special bug report for the networkmanager issue? +*solid-4.3.4-r2 (16 Dec 2009) + + 16 Dec 2009; Samuli Suominen <ssuominen@gentoo.org> + -solid-4.3.4-r1.ebuild, +solid-4.3.4-r2.ebuild, + files/solid-4.3.4-hal.patch: + Update HAL 0.5.14 patch wrt #296544 by Nate Weibley. Samuli commited a patch which includes this fix 3 days ago, if someone could test revision 2 it would be nice. Thanks in advance. (In reply to comment #33) > +*solid-4.3.4-r2 (16 Dec 2009) > + > + 16 Dec 2009; Samuli Suominen <ssuominen@gentoo.org> > + -solid-4.3.4-r1.ebuild, +solid-4.3.4-r2.ebuild, > + files/solid-4.3.4-hal.patch: > + Update HAL 0.5.14 patch wrt #296544 by Nate Weibley. > > Samuli commited a patch which includes this fix 3 days ago, > if someone could test revision 2 it would be nice. > Thanks in advance. > It happened that I tested solid-4.3.4-r2 already some days ago. Maybe Samuli could also fix what had been reported as BUG #297221. This leads to the same symptom (plasma-desktop crash), but has a different, yet similar cause. I'm only committing what has been reported AND committed upstream. ssuominen@unique ~/gentoo-x86/kde-base/solid $ head -n 8 files/solid-4.3.4-hal.patch http://bugs.gentoo.org/show_bug.cgi?id=295600 http://bugs.gentoo.org/show_bug.cgi?id=296544 http://websvn.kde.org/trunk/KDE/kdebase/workspace/solid/hal/halpower.cpp?r1=929945&r2=1035622&pathrev=1057980 http://websvn.kde.org/trunk/KDE/kdebase/workspace/solid/hal/halpower.cpp?r1=1035622&r2=1057980&pathrev=1057980 http://websvn.kde.org/trunk/KDE/kdebase/workspace/solid/hal/halpower.cpp?r1=1057980&r2=1062504&pathrev=1062504 http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/solid/control/powermanager.cpp?r1=923760&r2=1062504&pathrev=1062504 I can't see any reference to http://bugs.kde.org/ in bug 297221 and as such I can't be sure if the patch is valid or not. (In reply to comment #35) http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/solid/control/powermanager.cpp?r1=923760&r2=1062504&pathrev=1062504 > > I can't see any reference to http://bugs.kde.org/ in bug 297221 and as such I > can't be sure if the patch is valid or not. It isn't valid, because it's only a workaround, commenting out the hot thing. From what I do see from the diff above, it's a newly induced bug. I haven't investigated the problem further, therefore I haven't filed an additional report with KDE's bugzilla. But I w'd think it's the direct.at(0) method call too, which could also gain from being implemented more defensively. Else plasma-desktop could crash whith each udevd|hald|solid update. The bug on the kde bug tracker has now been closed, mentioning two commits: https://bugs.kde.org/show_bug.cgi?id=219333#c23 *** Bug 298213 has been marked as a duplicate of this bug. *** Should be fixed with solid-4.3.4-r3 |