Version: (using KDE KDE 3.1.2) Installed from: Gentoo Packages OS: Linux Sometime due normal operation, NOT WITH kicker, it crashed and must be restarted manually. from 5 Minutes to 60 Minutes it crashed at least one time. The output is nt very helpful. ;) But how to make better? (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 25820)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...0x4fd5bf67 in waitpid () from /lib/libpthread.so.0 #0 0x4fd5bf67 in waitpid () from /lib/libpthread.so.0
recompile with --enable-debug=full, so far it's useless ;(
Hello there. I compiled kdebase AND kdelibs with debug support and removed some gcc optimizations. This is the result. I hope it is more usefull now. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 24144)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x43d85f67 in waitpid () from /lib/libpthread.so.0 #0 0x43d85f67 in waitpid () from /lib/libpthread.so.0 #1 0x4348fcce in KCrash::defaultCrashHandler(int) () from /usr/kde/3.1/lib/libkdecore.so.4 #2 0x43d84e1a in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x44a147b7 in FuzzyClock::drawContents(QPainter*) () from /usr/kde/3.1/lib/kde3/clock_panelapplet.so #5 0x438cfcad in QFrame::paintEvent(QPaintEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #6 0x438667dd in QWidget::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #7 0x437d4544 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x437d3abb in QApplication::notify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #9 0x434035a9 in KApplication::notify(QObject*, QEvent*) () from /usr/kde/3.1/lib/libkdecore.so.4 #10 0x437a9a94 in QWidget::repaint(int, int, int, int, bool) () from /usr/qt/3/lib/libqt-mt.so.3 #11 0x44a14596 in FuzzyClock::updateClock() () from /usr/kde/3.1/lib/kde3/clock_panelapplet.so #12 0x44a19442 in ClockApplet::qt_invoke(int, QUObject*) () from /usr/kde/3.1/lib/kde3/clock_panelapplet.so #13 0x43832419 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/qt/3/lib/libqt-mt.so.3 #14 0x438322bd in QObject::activate_signal(int) () from /usr/qt/3/lib/libqt-mt.so.3 #15 0x43b14f6b in QTimer::timeout() () from /usr/qt/3/lib/libqt-mt.so.3 #16 0x438534e2 in QTimer::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #17 0x437d4544 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #18 0x437d3abb in QApplication::notify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #19 0x434035a9 in KApplication::notify(QObject*, QEvent*) () from /usr/kde/3.1/lib/libkdecore.so.4 #20 0x437af0d5 in QEventLoop::activateTimers() () from /usr/qt/3/lib/libqt-mt.so.3 #21 0x4378c8b8 in QEventLoop::processEvents(unsigned) () from /usr/qt/3/lib/libqt-mt.so.3 #22 0x437e8386 in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3 #23 0x437e8228 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #24 0x437d4771 in QApplication::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #25 0x42ce6a87 in main () from /usr/kde/3.1/lib/kicker.so #26 0x43ef27a7 in __libc_start_main () from /lib/libc.so.6
*** Bug 59968 has been marked as a duplicate of this bug. ***
Very interesting.. There were some earlier reports I saw, but can't find ATM, but this is hard to diagnose since it seems to not happen to developers trying to fix this :-(.. I've switched my clock to fuzzy right now, and will see if it happens to me, but I think it may be something settings-specific, too... One thing that may help is if you upload you clock config.. It's a file named clock_panelapplet_(a bunch of random stuff here)_rc; usually in ~/.kde/share/config/ Perhaps there is some specific combination of settings that's causing it to trigger..
Created attachment 1842 [details] first config file
Created attachment 1843 [details] second config file
Fuzzy clock is the clock with the words, right? I only use KDE in german translation. After I saw the cause for the crash, I changed to the normal clock and tadaaa, it worked like a charm. For the config files, I changed back to fuzzy, and attached those two files here for you. I really hope you find a clue, becuase I like the time presented that way very much. I also had this in earlier verions, the clock, not the crash, so I agree with you, that it is most likely a configuration problem. If I have some time, I play a bit.
It had to do with antialiasing and deviding by zero. It shouldn't occur anymore (Fixed in CVS)
*** Bug 56838 has been marked as a duplicate of this bug. ***
My bad I was thinking about the Analog bug I fixed and somehow put in Analog->Fuzzy
To Andrew Berry: What language were you using it with?
Another piece of ingormation that may be helpful:versions of kdebase and kde- i18n, if any.
In the Control Centre, I have country set to Canada. English GB is the first language, followed by English US. At the moment, I am now running the regular digital clock. Everything /seems/ stable (I've also upgraded the KDE RPMs I'm using). I'm going to switch to the fuzzy clock and see what happens.
Kicker has started crashing since I switched to the fuzzy clock. Here is the output from a crash when I ran kicker from a console. Hope it helps! WARNING: KDE detected X Error: BadDrawable (invalid Pixmap or Window parameter) \x09 Major opcode: \x0e QMetaObject::findSignal:KasTasker: Conflict with KasBar::configChanged() QMetaObject::findSignal:KasTasker: Conflict with KasBar::configChanged() QWidget (unnamed): deleted while being painted QPaintDevice: Cannot destroy paint device that is being painted kicker: crashHandler called
Thanks, that kind of helps... It's hard to do much when I can't reproduce it on my own box, but this gives a direction for trying to figure it out on paper.. (I first thought it had something to do w/how it handled strings on different translations; particularly since there was a possibility of it doing stupid things if one had slightly mismatched versions; but this message and that it happen with en_GB -- which I don't think differents from the en_US/untranslated text kind of kills that theory). I'll try to read through the routine again and see whether I can think of a way it can crash like that. Note that if someone feels sufficiently helpful, and can bear kicker being reallllyyyy slllowwwwww for a while, as well as has a build that's not stripped/built with -fomit-frame-pointer (how to tell: the backtrace of the crash should have roughly the same length as one in Comment #2), you could consider running it in Valgrind. (See developer.kde.org/~sewardj); that will probably provide really good information. (This just involved running kicker from a command line through something like valgrind --num-callers=12 kicker --nofork, and logging the output).
My commit fixing #69984 fixed the race leading to the "QPaintDevice: Cannot destroy paint device that is being painted " and I'm running FuzzyClock from HEAD permanently without any crash. So could the reporter retest this with latest CVS Head (Beta2 is not enough) and see whether the problem still persists?
Assumed to be fixed.