Version: 3.1 (using KDE 3.1.0) Installed from: Mandrake Linux Cooker i586 - Cooker Compiler: gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) OS: Linux (i686) release 2.4.19-16mdk korganizer crashes whenever I create a situation in which the to-do list is showing in the main window and should be showing some completed item, e.g.: 1) Mark an item "completed" in the mini to-do window (this works fine) and then select "View: To-do list" from the menu -- crash 2) Do the same thing, only first enable the "don't show completed items" filter. In this case there is no crash when I first view the to-do list, but there is a crash if I now disable the filter while the to-do list is showing 3) Do the same thing, with no completed items in the to-do list. In this case I can view the list with no problem, even with the "don't show completed items" filter disabled, but if I click in the check-box to mark an item completed with the filter disabled, I get a crash I tried running in a terminal window to see if there was any interesting debug output. The only thing I get is QMetaObject::findSignal:KOTodoListView: Conflict with KListView::doubleClicked(QListViewItem*,const QPoint&,int) but this happens when the to-do list is first displayed, which is not necessarily the same time as the crash occurs. The crash occurs silently when it comes and doesn't seem to mess up any data.
I was solved this problems select first "purge completed" from a "little list of to do" in the left pane of the window, and then wen I select the "complete list of to do", I see it with no crash! Kalos Bonasia
I also have this problem. The workaround in comment#1 is not really a fix - as soon as you mark a task as complete in the ToDo view, it crashes again.
This is fixed for me in the latest Mandrake RPMs (kdepim-3.1.1-2mdk).
Still broken for me in kdepim-3.1.1-3mdk.i586.rpm A little more information - if when using the ToDo view I set a task to 100% complete using the "Complete" column then this works. If however I click on the little box to the left of the task description, the tool still dies (most of the time, not always)
Created attachment 1468 [details] Post-mortem stack backtrace
I have this bug here too using KDE from Debian Unstable. Procedure: 1. rename .kde/share/config/korganizerrc and .kde/share/apps/korganizer to something else (to start with a clean state) 2. start korganizer 3. select menu View->To-Do List 4. create a new to-do item, simply set the name to foo and press OK. 5. click on the to-do checkbox 6. crash The console output is the following: david@nemesis david$ korganizer [[ Loading korganizer with all bells and whistles ]] QMetaObject::findSignal:KOTodoListView: Conflict with KListView::doubleClicked(QListViewItem*,const QPoint&,int) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::editEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::showEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::deleteEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::editEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::showEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::deleteEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::editEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::editEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::showEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::showEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::deleteEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::deleteEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::newEventSignal(QDateTime) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::newEventSignal(QDateTime,QDateTime) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::editEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::showEventSignal(Event*) QMetaObject::findSignal:KOAgendaView: Conflict with KOEventView::deleteEventSignal(Event*) [[ Switching to To-Do view ]] QMetaObject::findSignal:KOTodoListView: Conflict with KListView::doubleClicked(QListViewItem*,const QPoint&,int) [[ opening the To-Do dialog ]] QMetaObject::findSignal:KOEditorGeneralTodo: Conflict with KOEditorGeneral::openCategoryDialog() QMetaObject::findSignal:KOEditorGeneralTodo: Conflict with KOEditorGeneral::openCategoryDialog() QTime::setHMS Invalid time -1:-1:-1.000 QTime::setHMS Invalid time -1:-1:-1.000 [[ no more errors when I validate the to-do and check it out ]] Here, setting % complete to 100 still causes a crash. This bug is 100% reproductible here. On real-life examples, Korganizer sometimes gets in an infinite loop and goes to eat all available memory. Attached is the backtrace produced by gdb. I had to skip a repetitive part because otherwise it would have been to big. Since the problem seems to have something to do with font loading, I tried disabling anti-aliasing or setting the KDE fonts to Helvetica and Courrier, the bug still occured. david@nemesis david$ korganizer --version Qt: 3.1.1 KDE: 3.1.1 KOrganizer: 3.1.1
*** Bug 57757 has been marked as a duplicate of this bug. ***
*** Bug 57286 has been marked as a duplicate of this bug. ***
*** Bug 56925 has been marked as a duplicate of this bug. ***
*** Bug 57254 has been marked as a duplicate of this bug. ***
*** Bug 57255 has been marked as a duplicate of this bug. ***
*** Bug 57425 has been marked as a duplicate of this bug. ***
Fixed in the 3.1 branch. The fix will hopefully be in KDE 3.1.2. Fix in HEAD still pending.
Hi Andy, this bug should be fixed now in CVS HEAD. Thank you very much for this hint. Ciao, Tobias
No, this was only partially fixed. The fix solved the first two reported crashes (which I haven't been able to reproduce for quite some time now, anyway), but the third one still prevails (switch to ToDo View, mark any of the todos in the main todo view finished, and KOrganizer will still crash). My backtrace here is: [New Thread 16384 (LWP 18481)] 0x412d0bb5 in waitpid () from /lib/libpthread.so.0 #0 0x412d0bb5 in waitpid () from /lib/libpthread.so.0 #1 0x40acf680 in KCrash::defaultCrashHandler(int) () from /usr/lib/libkdecore.so.4 #2 0x412cf98d in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x40ef7a78 in QListView::repaintItem(QListViewItem const*) const () from /usr/lib/libqt-mt.so.3 #5 0x40ef7a49 in QListViewItem::repaint() const () from /usr/lib/libqt-mt.so.3 #6 0x40efa4ce in QCheckListItem::setOn(bool) () from /usr/lib/libqt-mt.so.3 #7 0x40efa2be in QCheckListItem::activate() () from /usr/lib/libqt-mt.so.3 #8 0x40ef3702 in QListView::contentsMousePressEventEx(QMouseEvent*) () from /usr/lib/libqt-mt.so.3 #9 0x40ef33b6 in QListView::contentsMousePressEvent(QMouseEvent*) () from /usr/lib/libqt-mt.so.3 #10 0x400e1ee6 in KOTodoListView::contentsMousePressEvent(QMouseEvent*) ( this=0x8584558, e=0xbffff0d0) at ../korganizer/kotodoview.cpp:242 #11 0x40f1c6fd in QScrollView::viewportMousePressEvent(QMouseEvent*) () from /usr/lib/libqt-mt.so.3 #12 0x40f1c15b in QScrollView::eventFilter(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #13 0x40ef2edc in QListView::eventFilter(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #14 0x40e39e7c in QObject::activate_filters(QEvent*) () from /usr/lib/libqt-mt.so.3 #15 0x40e39dca in QObject::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #16 0x40e68f4a in QWidget::event(QEvent*) () from /usr/lib/libqt-mt.so.3 #17 0x40de7c66 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #18 0x40de751e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3 #19 0x40a4b1f7 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdecore.so.4 #20 0x40d96526 in QETWidget::translateMouseEvent(_XEvent const*) () from /usr/lib/libqt-mt.so.3 #21 0x40d9417f in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libqt-mt.so.3 #22 0x40da7141 in QEventLoop::processEvents(unsigned) () from /usr/lib/libqt-mt.so.3 #23 0x40df9223 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3 #24 0x40df90e0 in QEventLoop::exec() () from /usr/lib/libqt-mt.so.3 #25 0x40de7e60 in QApplication::exec() () from /usr/lib/libqt-mt.so.3 #26 0x08053f38 in main (argc=1, argv=0xbffffb74) at ../../korganizer/main.cpp:94 Note that this only happens if you mark the todo finished in the big todo view. If you have both the small one on the left, and the main todo view, you can mark todos finished in the left list without crash. Only the main todo view crashes KOrganizer. Reinhold
Hi, now this bug is really fixed ;) Ciao, Tobias
Subject: kdepim/korganizer CVS commit by kainhofe: Finally, I found the real problem that crashed korganizer when you marked a todo completed using the checkbox. The problem was that stateChange of the KOTodoViewItem emitted the signal todoChanged, which called updateTodoViews(), which rebuilt the todo lists. This meant also calling stateChange of the same item again, and then the crash occured. The fix is to postpone the updateViews until the stateChange function has exited. So, I'm now using QTimer::singleShot to call that slot. Also, moved the connect calls for the todo list and the todo view to KOViewManager, so the two todo lists are always connected to the same signals/slots. Also, now that marking todo items finished worked again, I could finally test my patch for unding this action. It works, so now bug 60670 is fixed. CCMAIL: 60670-done@bugs.kde.org, 56348@bugs.kde.org, tokoe@kde.org PS: The way bug 56348 (the crash which i finally fixed now) was closed (revision 1.36 of http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdepim/korganizer/koviewmanager.cpp ) collides with item 12 of the CVS Policies (http://developer.kde.org/policies/commitpolicy.html#12)... M +8 -25 calendarview.cpp 1.214 M +1 -1 kotodoview.h 1.56 M +31 -22 koviewmanager.cpp 1.42 M +7 -5 koviewmanager.h 1.12
Is there a new build out that fixes this? Thanks! John
The fix will be in KDE 3.2 (beta2 was tagged last weekend). Reinhold