Version: (using Devel) Installed from: Compiled sources Application: System Monitor (ksysguard), signal SIGSEGV 0x00007f7f8b898621 in nanosleep () from /lib/libc.so.6 [Current thread is 0 (LWP 17740)] Thread 2 (Thread 0x41408950 (LWP 17741)): #0 0x00007f7f8b8cf482 in select () from /lib/libc.so.6 #1 0x00007f7f8d400aa1 in QProcessManager::run (this=0x68b410) at io/qprocess_unix.cpp:301 #2 0x00007f7f8d3166cf in QThreadPrivate::start (arg=0x68b410) at thread/qthread_unix.cpp:185 #3 0x00007f7f8d08b3ea in start_thread () from /lib/libpthread.so.0 #4 0x00007f7f8b8d6c6d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f7f9036c6f0 (LWP 17740)): [KCrash Handler] #5 0x00007f7f8ff2cc35 in FancyPlotter::timerTick (this=0xaae650) at /home/kde-devel/dev/kde4/trunk/src/kdebase/workspace/ksysguard/gui/SensorDisplayLib/FancyPlotter.cc:393 #6 0x00007f7f8ff2063a in KSGRD::SensorDisplay::qt_metacall (this=0xaae650, _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x7fff983a5260) at /home/kde-devel/dev/kde4/trunk/build/kdebase/workspace/ksysguard/gui/SensorDisplay.moc:87 #7 0x00007f7f8ff2f4c3 in FancyPlotter::qt_metacall (this=0xaae650, _c=QMetaObject::InvokeMetaMethod, _id=33, _a=0x7fff983a5260) at /home/kde-devel/dev/kde4/trunk/build/kdebase/workspace/ksysguard/gui/FancyPlotter.moc:67 #8 0x00007f7f8d43afad in QMetaObject::activate (sender=0x9d0980, from_signal_index=4, to_signal_index=4, argv=0x0) at kernel/qobject.cpp:3022 #9 0x00007f7f8d43b533 in QMetaObject::activate (sender=0x9d0980, m=0x7f7f8d75b7e0, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3092 #10 0x00007f7f8d484b30 in QTimer::timeout (this=0x9d0980) at .moc/debug-shared/moc_qtimer.cpp:126 #11 0x00007f7f8d4463c0 in QTimer::timerEvent (this=0x9d0980, e=0x7fff983a5b00) at kernel/qtimer.cpp:257 #12 0x00007f7f8d438b4e in QObject::event (this=0x9d0980, e=0x7fff983a5b00) at kernel/qobject.cpp:1111 #13 0x00007f7f8c4ede6b in QApplicationPrivate::notify_helper (this=0x6877d0, receiver=0x9d0980, e=0x7fff983a5b00) at kernel/qapplication.cpp:3803 #14 0x00007f7f8c4ee17a in QApplication::notify (this=0x683e70, receiver=0x9d0980, e=0x7fff983a5b00) at kernel/qapplication.cpp:3393 #15 0x00007f7f8e2fbb64 in KApplication::notify (this=0x683e70, receiver=0x9d0980, event=0x7fff983a5b00) at /home/kde-devel/dev/kde4/trunk/src/kdelibs/kdeui/kernel/kapplication.cpp:307 #16 0x00007f7f8d422d11 in QCoreApplication::notifyInternal (this=0x683e70, receiver=0x9d0980, event=0x7fff983a5b00) at kernel/qcoreapplication.cpp:587 #17 0x00007f7f8d4273df in QCoreApplication::sendEvent (receiver=0x9d0980, event=0x7fff983a5b00) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:209 #18 0x00007f7f8d45b67d in QTimerInfoList::activateTimers (this=0x68b030) at kernel/qeventdispatcher_unix.cpp:557 #19 0x00007f7f8d458cbf in timerSourceDispatch (source=0x68afd0) at kernel/qeventdispatcher_glib.cpp:160 #20 0x00007f7f87bd0d3b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #21 0x00007f7f87bd450d in ?? () from /usr/lib/libglib-2.0.so.0 #22 0x00007f7f87bd46cb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #23 0x00007f7f8d457d60 in QEventDispatcherGlib::processEvents (this=0x6876d0, flags=@0x7fff983a5d60) at kernel/qeventdispatcher_glib.cpp:319 #24 0x00007f7f8c5a6cc7 in QGuiEventDispatcherGlib::processEvents (this=0x6876d0, flags=@0x7fff983a5dc0) at kernel/qguieventdispatcher_glib.cpp:198 #25 0x00007f7f8d41f738 in QEventLoop::processEvents (this=0x7fff983a5e80, flags=@0x7fff983a5e40) at kernel/qeventloop.cpp:143 #26 0x00007f7f8d41f934 in QEventLoop::exec (this=0x7fff983a5e80, flags=@0x7fff983a5ea0) at kernel/qeventloop.cpp:194 #27 0x00007f7f8d4236ff in QCoreApplication::exec () at kernel/qcoreapplication.cpp:845 #28 0x00007f7f8c4edbcc in QApplication::exec () at kernel/qapplication.cpp:3331 #29 0x00007f7f8ff6760b in kdemain (argc=1, argv=0x7fff983a6408) at /home/kde-devel/dev/kde4/trunk/src/kdebase/workspace/ksysguard/gui/ksysguard.cc:590 #30 0x00000000004008b7 in main (argc=1, argv=0x7fff983a6408) at /home/kde-devel/dev/kde4/trunk/build/kdebase/workspace/ksysguard/gui/ksysguard_dummy.cpp:3
We received a report about this crash downstream at https://launchpad.net/bugs/377774
I have the same (or at leas similar) bug, but it is not stable. I've noticed that it is fired more often when deleting the sensors. I assume that the problem may be with the lack of thread sync. If sensor is deleted and at the same time another thread tries to update the graph (or just seek through the array)
SVN commit 975473 by johnflux: Stupid hack to fix crash when deleting sensors I can't think of a better way to fix it, because of this stupid communication protocol code. I hope I can switch to dbus for communication and kill of all these types of bugs once and for all BUG:179305 M +8 -6 FancyPlotter.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=975473
The patch below is to fix this bug. As discussed with John there was still some problem after the previous patch. This fix this problem, in addition with the label color not being updated, and the order not being updated.
Created attachment 34205 [details] Bug fix for 179305 + color and order not being updated after setting change This is a rewrite of FancyPlotter and SignalPlotter to now rely on the beamId instead of index of sensor which got out of sync before and caused crash. Note that the same problem is present in other Plotter, e.g. the bar one. The common code could be pulled up in SensorDisplay and a similar solution written for other plotter that are affected by this bug. This is a svn diff of latest code as of today.
Thanks mlconsultant. Your patch looks good, but unfortunately you've removed all the summationName code! This is used so that sensors can be summed together. If you look at the networking graph, for example, (the last graph on the second graph) the data comes in from lots of different interfaces (lo, eth0, eth1, wifi0, etc) but then all the numbers get added together and displayed on the graph as just one or two lines. I didn't want your change to go to waste though and spent the last few hours trying to putting the summationName stuff back in, but I think now it might be better to just try a clean attempt to writing the patch again. It would be nice to avoid using QHash's as well - we need the graphs to take as little CPUs as possible, so replacing a QList with three or so QHash lookups for every number is a bit painful! Do you want another crack at trying to do this? Thanks John
As for the summation part I thought it shouldn't be implemented in the sensor code but through some type of aggregator pattern higher up in the hierarchy. As for the QHash, it is slightly less efficient then a QList but more appropriate for our scenario I believe. In addition, it doesn't take into account that if using a QList you need extra code to adjust the beamId of all sensors and adjust all the QList that referred to it, and it also adds some synchronization problems of keeping everything in sync while processing answers which means locking/partial locking of all QList affected by the beamId while we are adjusting. At the end of the day just the performance aspect alone might not even make a big difference. I can work on an aggregator to restore the summation part, I shouldn't have changed it in the same patch however. Here is where a svn branch would be useful...
SVN commit 978091 by johnflux: Fix problems when deleting or reordering sensors Inspiration for the patch came from mlconsultant's patch and discussions. BUG:179305 M +75 -26 FancyPlotter.cc M +4 -1 FancyPlotter.h M +0 -11 SensorDisplay.cc M +0 -1 SensorDisplay.h M +7 -6 SignalPlotter.h WebSVN link: http://websvn.kde.org/?view=rev&revision=978091
*** Bug 199032 has been marked as a duplicate of this bug. ***
*** Bug 185061 has been marked as a duplicate of this bug. ***