After logging in via kdm or console, the kde loading splash screen takes an unusually long time (~30 seconds or so) and then I get an error message saying plasma workspace crashed. That message is followed by another error message saying the kde daemon crashed. After this KDE does not start up at all, there is just the background and a working cursor. I tried moving my .kde directory, and also installed plasma-workspace with a variety of use flags (including all of them unset) but neither fixed the problem. Reproducible: Always Steps to Reproduce: 1. emerge kde-base/kde-meta-4.3.0 2. try to login 3. fail Actual Results: KDE doesn't start Expected Results: KDE should have started #emerge --info Portage 2.1.6.13 (default/linux/x86/2008.0, gcc-4.4.1, glibc-2.10.1-r0, 2.6.30-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.30-gentoo-r5-i686-Intel-R-_Pentium-R-_Dual_CPU_T3400_@_2.16GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 19 Aug 2009 02:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p28 dev-lang/python: 2.6.2-r1, 3.1.1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.4-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://mirrors.cs.wmich.edu/gentoo http://gentoo.cites.uiuc.edu/pub/gentoo/ ftp://gentoo.cites.uiuc.edu/pub/gentoo/ http://lug.mtu.edu/gentoo/ ftp://lug.mtu.edu/gentoo/ " LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY=" " SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acl aim alsa bash-completion berkdb bzip2 cddb cli cracklib crypt cups dbus dri dvd dvdr emacs fftw fortran gdbm gpm hal hddtemp hdf5 iconv imagemagick imap ipv6 isdnlog jpeg jpeg2k kde kontact latex libnotify lm_sensors mudflap mysql ncurses nls nptl nptlonly nsplugin offensive ogg opengl openmp oscar pam pcre pdf perl phonon pppd python qt3 qt3support qt4 qt4support readline reflection session solid spl ssl svg sysfs tcpd truetype unicode vorbis webkit win32codecs x86 xcomposite xine xinerama xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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?
http://websvn.kde.org/trunk/KDE/kdebase/workspace/solid/hal/halpower.cpp?r1=929945&r2=1035622
+*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