| Summary: | Gentoo's kde-base/solid-4.3.4-r2 crashes plasma-desktop-4.3.4 on hardened [QtPrivate::QStringList_contains, QStringList::contains, HalPower::brightness] (post bug 217316) | ||
|---|---|---|---|
| Product: | [Unmaintained] solid | Reporter: | Hugo Mildenberger <Hugo.Mildenberger> |
| Component: | general | Assignee: | Kevin Ottens <ervin> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | andres.mat, andresbajotierra, armaert, BenBE, benoit.schwinden, ck_enitsirhc, dariush, dezerb, ervin, gladhorn, jeff, jnsc, jomarcar, jwhibdon, kdebugs, kdebugs, nweibley, plasma-bugs, qfeng.chen, rameshsurya335, robert, sebas, tim, u75620712, waynenail |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
This was reported at bug 217316, and that fix was implemented. Regards *** This bug has been marked as a duplicate of bug 217316 *** Ahem, are you sure? The stack from bug 217316 looks very different: Thread 1 (Thread 0xb468b930 (LWP 15537)): [KCrash Handler] #6 qNumVariantToHelper<double> (this=0x0, ok=0x0) at kernel/qvariant.cpp:2361 #7 QVariant::toDouble (this=0x0, ok=0x0) at kernel/qvariant.cpp:2475 #8 0xa8f832ca in HalPower::brightness (this=0x8678918, device=...) at /var/tmp/portage/kde-base/solid-4.3.4/work/solid-4.3.4/solid/hal/halpower.cpp:396 #9 0xa928ef26 in Solid::Control::PowerManager::brightness (device=...) at /var/tmp/portage/kde-base/solid-4.3.4/work/solid-4.3.4/libs/solid/control/powermanager.cpp:198 #10 0xa903f155 in ?? () from /usr/lib/kde4/plasma_applet_battery.so #11 0xbfd5e07c in ?? () #12 0x00000000 in ?? () The situation matches
This frame matches... (even the line number)
#2 0x40644a38 in Solid::Control::PowerManager::brightness (device=@0x5a9b9fe8)
at
/usr/src/debug/kde-base/solid-4.3.4-r2/solid-4.3.4/libs/solid/control/powermanager.cpp:198
and "HalPower::brightness " matches too.. (I was expecting little differences..)
but well. it could be reopened...
Huge, are you using kde-base/solid-4.3.4-r2 from Gentoo portage? Sorry *Hugo! My bad. I'm thinking this may be an issue I was wondering about re: the enumeration of the brightness controllable devices from hal. IIRC the list of device can be returned uninitialized which I thought odd. I'm not on my laptop right now but I'll look into it if you're using 4.3.4-r2 from portage. It sounds like you are... ? Yes, I'm using Gentoo's kde-base/solid-4.3.4-r2. That package seems to contain the patches from bug 217316. You can also look to my comment at http://bugs.gentoo.org/show_bug.cgi?id=281988#c30 and below, especially for Samuli's. The situation I described in #30 was exacly the same a in bug 217316, and the patches resulting from that bug, now contained in solid-4.3.4-r2, did lead to the current issue. I don't know much about HAL (except for HAL-9000), but the interface appears to change constantly. Hence checking rigorously any message before accessing them could make numerous applications more stable. *** Bug 220139 has been marked as a duplicate of this bug. *** *** Bug 220055 has been marked as a duplicate of this bug. *** *** Bug 220507 has been marked as a duplicate of this bug. *** *** Bug 221527 has been marked as a duplicate of this bug. *** *** Bug 221567 has been marked as a duplicate of this bug. *** (In reply to comment #6) > Yes, I'm using Gentoo's kde-base/solid-4.3.4-r2. That package seems to contain > the patches from bug 217316. You can also look to my comment at > http://bugs.gentoo.org/show_bug.cgi?id=281988#c30 and below, especially for > Samuli's. The situation I described in #30 was exacly the same a in bug 217316, > and the patches resulting from that bug, now contained in solid-4.3.4-r2, did > lead to the current issue. I don't know much about HAL (except for HAL-9000), > but the interface appears to change constantly. Hence checking rigorously any > message before accessing them could make numerous applications more stable. Hugo, I'm assuming you used to have screen brightness control before? Or perhaps I'm assuming incorrectly and you are on a desktop or without brightness control. It is weird to me that the check controls.size() == 0 doesn't catch for you, but with the HAL changes it is increasingly likely that such a check is finding new dim-capable LEDs. I'll get started on a patch test-case to post to your bug on the gentoo bugtracker for you to test since I can't reproduce this problem, but in the meantime do you mind posting the results of running the following from a terminal: hal-find-by-capability --capability laptop_panel hal-find-by-capability --capability keyboard_backlight Thanks. After svn-upping I noticed revision 1069849 http://websvn.kde.org/?view=revision&revision=1069849 which looks like what I was thinking. Hugo can you test this revision and see if it fixes your issue? Nate, I don't use brightness control, at least not actively, because this is an old HP/compaq nx9110 notebook without a battery. However, this notebook should be able to dim the screen. Here is the output of hal-find-by-capability, which you requested above: $ hal-find-by-capability --capability laptop_panel [ no output --hm] $ hal-find-by-capability --capability keyboard_backlight /org/freedesktop/Hal/devices/leds_b43_phy0_tx /org/freedesktop/Hal/devices/leds_b43_phy0_rx /org/freedesktop/Hal/devices/leds_b43_phy0_radio [ end of list --hm ] Ok, using kde-base/solid-4.3.4-r2 and copying powermanager.cpp over from http://websvn.kde.org/?view=revision&revision=1069849, plasma-desktop works again, while plain kde-base/solid-4.3.4-r2 still does not. But I really wonder (and I'm unable to analyze it further because gdb only handles core dumps correctly on hardened gentoo) why solid crashed in #line 318 below: "*that" must contain an element, but the memory dump doesn't look like that: $5 = {<QList<QString>> = {{p = {static shared_null = {ref = {_q_value = 3174}, alloc = 0, begin = 0, end = 0, sharable = 1, array = {0x0}}, d = 0x17304fe8}, d = 0x17304fe8}}, <No data fields>} 313 QBool QtPrivate::QStringList_contains(const QStringList *that, const QString &str, 314 Qt::CaseSensitivity cs) 315 { 316 for (int i = 0; i < that->size(); ++i) { 317 const QString & string = that->at(i); 318 if (string.length() == str.length() && str.compare(string, cs) == 0) 319 return QBool(true); 320 } 321 return QBool(false); 322 } Having compiled solid now with -Weffc++, I got many warnings about uninitialized member variables. Just say so if I should attach a log file. The crash in my computer is caused by the "battery monitor" widget. I do the following: stop the hal service, run plasma-desktop, remove battery monitor widget stop plasma-desktop, run hal service again run plasma-desktop again -- it works well, add the battery monitor widget cause the plasma-desktop crash immediately. plasma-desktop restarts without the battery monitor widget and work well. May be the plasma-desktop should be redesigned to be more robust to make sure when a widget can not work properly won't kill the hold plasma-desktop. On Wed, Jan 6, 2010 at 9:31 PM, Hugo Mildenberger <Hugo.Mildenberger@namir.de> wrote: > https://bugs.kde.org/show_bug.cgi?id=219333 > > > > > > --- Comment #14 from Hugo Mildenberger <Hugo Mildenberger namir de> 2010-01-06 21:31:25 --- > Nate, I don't use brightness control, at least not actively, because this is an > old HP/compaq nx9110 notebook without a battery. However, this notebook should > be able to dim the screen. Here is the output of hal-find-by-capability, which > you requested above: > > $ hal-find-by-capability --capability laptop_panel > [ no output --hm] > > $ hal-find-by-capability --capability keyboard_backlight > /org/freedesktop/Hal/devices/leds_b43_phy0_tx > /org/freedesktop/Hal/devices/leds_b43_phy0_rx > /org/freedesktop/Hal/devices/leds_b43_phy0_radio > [ end of list --hm ] > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > (In reply to comment #15) > Ok, using kde-base/solid-4.3.4-r2 and copying powermanager.cpp over from > http://websvn.kde.org/?view=revision&revision=1069849, plasma-desktop works > again, while plain kde-base/solid-4.3.4-r2 still does not. Ok good. So I guess this can be patched downstream in portage to fix the crash for hardened users until KDE 4.4 is released. (In reply to comment #15) > But I really wonder (and I'm unable to analyze it further because gdb only > handles core dumps correctly on hardened gentoo) why solid crashed in #line 318 > below: "*that" must contain an element, but the memory dump doesn't look like > that: > > $5 = {<QList<QString>> = {{p = {static shared_null = {ref = {_q_value = 3174}, > alloc = 0, begin = 0, end = 0, sharable = 1, array = {0x0}}, > d = 0x17304fe8}, d = 0x17304fe8}}, <No data fields>} > > 313 QBool QtPrivate::QStringList_contains(const QStringList *that, const > QString &str, > 314 Qt::CaseSensitivity cs) > 315 { > 316 for (int i = 0; i < that->size(); ++i) { > 317 const QString & string = that->at(i); > 318 if (string.length() == str.length() && str.compare(string, cs) > == 0) > 319 return QBool(true); > 320 } > 321 return QBool(false); > 322 } > > Having compiled solid now with -Weffc++, I got many warnings about > uninitialized member variables. Just say so if I should attach a log file. Whats going on is this: without rev 1069849 the overall list of brightness control devices was not equal to zero, but the list of *Screen* brightness control devices was equal to zero. Thus powermanager.cpp:198 was hit which calls controls.keys(Solid::Control::PowerManager::Screen).at(0). This is where that crash happens. On line 317 a reference is made to the item at 0, but there is no item at zero because we limited to keys (which are the hal device names) by values matching Screen... so when line 318 is called you're getting a null reference and a crash. *** Bug 221633 has been marked as a duplicate of this bug. *** *** Bug 221696 has been marked as a duplicate of this bug. *** *** Bug 221681 has been marked as a duplicate of this bug. *** Last debian sid update (of today) solved my problem ! *** Bug 221850 has been marked as a duplicate of this bug. *** The proper fix has been committed to KDE 4.4. debian backported these related commits: http://websvn.kde.org/?view=revision&revision=1057980 http://websvn.kde.org/?view=revision&revision=1069849 *** Bug 220190 has been marked as a duplicate of this bug. *** *** Bug 222635 has been marked as a duplicate of this bug. *** *** Bug 223621 has been marked as a duplicate of this bug. *** *** Bug 223748 has been marked as a duplicate of this bug. *** - Which package versions are supposed to fix this bug on Debian ? Regards *** Bug 224748 has been marked as a duplicate of this bug. *** These are the changes from debian:
$ aptitude changelog kdebase-workspace
kdebase-workspace (4:4.3.4-4) unstable; urgency=low
* Backport r1069849 in order to fix crash with hal 0.5.14 (yet another
attempt). Merged into patch 90_work_with_hal_0.5.14_svn_r1062504.diff
(Closes: #556468).
-- Modestas Vainius <modax@debian.org> Wed, 06 Jan 2010 20:11:33 +0200
kdebase-workspace (4:4.3.4-3) unstable; urgency=high
* Backport parts of r1035622/r1057980 to fix
90_work_with_hal_0.5.14_svn_r1062504.diff (Closes: #556468).
*** Bug 225014 has been marked as a duplicate of this bug. *** Hi. I recently upgraded on a different computer and KDE (debian squeeze) works perfectly. Unfortunately on my macbook is not working yet, so I need to do further research. Kind regards. Jose Miguel Martinez Carrasco --------------------------------------- http://www.jm2dev.com http://identi.ca/jm2dev http://twitter.com/jm2dev On Tue, Jan 26, 2010 at 8:43 PM, Dario Andres <andresbajotierra@gmail.com>wrote: > https://bugs.kde.org/show_bug.cgi?id=219333 > > > > > > --- Comment #28 from Dario Andres <andresbajotierra gmail com> 2010-01-26 > 21:42:48 --- > - Which package versions are supposed to fix this bug on Debian ? > Regards > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > *** Bug 225399 has been marked as a duplicate of this bug. *** *** Bug 225858 has been marked as a duplicate of this bug. *** *** Bug 227257 has been marked as a duplicate of this bug. *** *** Bug 227827 has been marked as a duplicate of this bug. *** According to bug 227827, this is still happening even with the most updated package on Debian... - Should this report be reopened ? May be KDE SC 4.3.5 fixes this (4.4.0 should be properly fixed) Regards *** Bug 227856 has been marked as a duplicate of this bug. *** |
Version: Qt: 4.6.0 KDE: 4.3.4 (KDE 4.3.4) Plasma Workspace: 0.3 (using KDE 4.3.4) Compiler: gcc 4.3.4 Gentoo 4.3.4 p1.0, pie-10.1.5 OS: Linux Installed from: Gentoo Packages As already reported on Gentoo's bugzilla, solid again crashes plasma-desktop when accessing hal attributes. #0 0x4e084919 in QtPrivate::QStringList_contains (that=0x5a9b9db8, str=@0x4e2570a8, cs=Qt::CaseSensitive) at tools/qstringlist.cpp:318 #1 0x403d5207 in HalPower::brightness (this=0x1150d180, device=@0x4e2570a8) at /usr/include/qt4/QtCore/qstringlist.h:171 #2 0x40644a38 in Solid::Control::PowerManager::brightness (device=@0x5a9b9fe8) at /usr/src/debug/kde-base/solid-4.3.4-r2/solid-4.3.4/libs/solid/control/powermanager.cpp:198 #3 0x404b91bf in Battery::initExtenderItem (this=0x1142e058, item=0x1161c660) at/usr/src/debug/kde-base/plasma-workspace-4.3.4/plasma-workspace-4.3.4/plasma/applets/battery/battery.cpp:406 #4 0x4ee9d052 in Plasma::ExtenderPrivate::loadExtenderItems (this=0x11616fb8) at /usr/src/debug/kde-base/kdelibs-4.3.4/kdelibs-4.3.4/plasma/extender.cpp:659 Here is a *workaround* (not a patch), successfully tested with sys-apps/hal-5.4.14 --- solid/control/powermanager.cpp.orig 2009-12-16 20:58:25.000000000 +0100 +++ solid/control/powermanager.cpp 2009-12-16 21:02:14.000000000 +0100 @@ -195,8 +195,12 @@ } else { +#if 0 return_SOLID_CALL(Ifaces::PowerManager *, globalPowerManager->managerBackend(), false, brightness(controls.keys(Solid::Control::PowerManager::Screen).at(0))); +#else + return false; +#endif I guess one reason is the direct.at(0) method call introduced by http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/solid/control/powermanager.cpp?r1=923760&r2=1062504&pathrev=1062504 which could also gain from being implemented more defensively. Else plasma-desktop could crash whith each udevd|hald|solid update. For a more complete backtrace also containing local variables, please see attachment to http://bugs.gentoo.org/show_bug.cgi?id=297221