Summary: | crash while deleting messages during sync | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | George Staikos <staikos> |
Component: | disconnected IMAP | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | dominik.tritscher, dufferin, hub, kde-bugzilla, kdebugs, lure, m.wege, markus |
Priority: | NOR | Keywords: | triaged |
Version: | SVN (3.5 branch) | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
George Staikos
2005-01-17 22:58:46 UTC
I've also seen such a behavior. The problem seems to be the deletion right then when the trash folder is synced (mine is on IMAP). I gonna provide a backtrace next times this will happen. Still getting it with HEAD [KCrash handler] #7 0x42b28985 in KMail::CachedImapJob::slotPutMessageInfoData ( this=0x8d8b9f0, job=0x720072, data=@0x899d930) at cachedimapjob.cpp:430 #8 0x42b2ac02 in KMail::CachedImapJob::qt_invoke (this=0x8d8b9f0, _id=9, _o=0xbfffe520) at qucom_p.h:312 CVS commit by burghard: Check if the message is valid. George, can you test this? CCMAIL:97274@bugs.kde.org M +1 -1 cachedimapjob.cpp 1.62 --- kdepim/kmail/cachedimapjob.cpp #1.61:1.62 @@ -424,5 +424,5 @@ void CachedImapJob::slotPutMessageInfoDa if ( it == account->jobsEnd() ) return; - if (data.find("UID") != -1) + if ( data.find("UID") != -1 && mMsg ) { int uid = (data.right(data.length()-4)).toInt(); No, still crashes same as before: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1108097888 (LWP 5069)] [KCrash handler] #7 0x00000019 in ?? () #8 0x42b35455 in KMail::CachedImapJob::slotPutMessageInfoData ( this=0x88e89e8, job=0x88d3588, data=@0x88721d8) at cachedimapjob.cpp:430 #9 0x42b376d2 in KMail::CachedImapJob::qt_invoke (this=0x88e89e8, _id=9, _o=0xbfffe520) at qucom_p.h:312 #10 0x4165f753 in QObject::activate_signal (this=0x899eba0, clist=0x899f260, o=0xbfffe520) at qobject.cpp:2357 #11 0x40b499bc in KIO::Job::infoMessage (this=0x899eba0, t0=0x899eba0, t1=@0x83ed458) at jobclasses.moc:183 #12 0x40b49a00 in KIO::SimpleJob::slotInfoMessage (this=0x88d3588, msg=@0x83ed458) at job.cpp:564 #13 0x40b4fc10 in KIO::SimpleJob::qt_invoke (this=0x899eba0, _id=9, _o=0xbfffe680) at qucom_p.h:449 I guess mMsg is just invalid. I think valgrinding it is the only choice. Dump a bunch of email into the (dimap) trash, have one ready in (dimap) inbox, sync, and when it's uploading the trash, delete the message from inbox. I can't valgrind it right now. kmail: [void KMHeaders::slotMoveCompleted(KMCommand*)] 1 ==14107== ==14107== Invalid read of size 4 ==14107== at 0x1BC72D7C: KMMoveCommand::execute() (kmmsgbase.h:126) ==14107== by 0x1BC7385F: KMCommand::slotPostTransfer(KMCommand::Result) (kmcommands.cpp:207) ==14107== by 0x1BC73D04: KMCommand::qt_invoke(int, QUObject*) (qucom_p.h:312) ==14107== by 0x1BC74062: KMMenuCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2436) ==14107== by 0x1BC740B4: KMMoveCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2616) ==14107== by 0x1BC74142: KMDeleteMsgCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2691) ==14107== by 0x1D63D752: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2357) ==14107== by 0x1BC738EB: KMCommand::messagesTransfered(KMCommand::Result) (kmcommands.moc:126) ==14107== by 0x1BC74C5C: KMCommand::transferSelectedMsgs() (kmcommands.cpp:301) ==14107== by 0x1BC74EC3: KMCommand::slotStart() (kmcommands.cpp:199) ==14107== by 0x1BC73D12: KMCommand::qt_invoke(int, QUObject*) (kmcommands.moc:147) ==14107== by 0x1BC74062: KMMenuCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2436) ==14107== by 0x1BC740B4: KMMoveCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2616) ==14107== by 0x1BC74142: KMDeleteMsgCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2691) ==14107== by 0x1D63D752: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2357) ==14107== by 0x1D995A9F: QSignal::signal(QVariant const&) (moc_qsignal.cpp:100) ==14107== by 0x1D65AF5E: QSignal::activate() (qsignal.cpp:212) ==14107== by 0x1D662482: QSingleShotTimer::event(QEvent*) (qtimer.cpp:277) ==14107== by 0x1D5DA9D2: QApplication::internalNotify(QObject*, QEvent*) (qapplication.cpp:2635) ==14107== by 0x1D5D9E8F: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:2358) ==14107== by 0x1D0FA7F9: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:549) ==14107== by 0x1D570396: QApplication::sendEvent(QObject*, QEvent*) (qapplication.h:491) ==14107== by 0x1D5C8BE1: QEventLoop::activateTimers() (qeventloop_unix.cpp:558) ==14107== by 0x1D582114: QEventLoop::processEvents(unsigned) (qeventloop_x11.cpp:389) ==14107== by 0x1D5EEC0D: QEventLoop::enterLoop() (qeventloop.cpp:198) ==14107== by 0x1D5EEB29: QEventLoop::exec() (qeventloop.cpp:145) ==14107== by 0x1D5DAB52: QApplication::exec() (qapplication.cpp:2758) ==14107== by 0x804ACCF: main (kapplication.h:218) ==14107== Address 0x1F65E80C is 4 bytes inside a block of size 96 free'd ==14107== at 0x1B90627F: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck.so) ==14107== by 0x1BA690AE: KMMessage::~KMMessage() (kmmessage.cpp:191) ==14107== by 0x1BBA4A1E: KMMsgList::set(unsigned, KMMsgBase*) (qmemarray.h:102) ==14107== by 0x1BC95EB6: KMFolderIndex::setIndexEntry(int, KMMessage*) (kmfolderindex.cpp:461) ==14107== by 0x1BB4198A: FolderStorage::unGetMsg(int) (folderstorage.cpp:503) ==14107== by 0x1BB2232B: KMFolder::unGetMsg(int) (kmfolder.cpp:260) ==14107== by 0x1BC72A36: KMMoveCommand::execute() (kmcommands.cpp:1855) ==14107== by 0x1BC7385F: KMCommand::slotPostTransfer(KMCommand::Result) (kmcommands.cpp:207) ==14107== by 0x1BC73D04: KMCommand::qt_invoke(int, QUObject*) (qucom_p.h:312) ==14107== by 0x1BC74062: KMMenuCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2436) ==14107== by 0x1BC740B4: KMMoveCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2616) ==14107== by 0x1BC74142: KMDeleteMsgCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2691) ==14107== by 0x1D63D752: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2357) ==14107== by 0x1BC738EB: KMCommand::messagesTransfered(KMCommand::Result) (kmcommands.moc:126) ==14107== by 0x1BC74C5C: KMCommand::transferSelectedMsgs() (kmcommands.cpp:301) ==14107== by 0x1BC74EC3: KMCommand::slotStart() (kmcommands.cpp:199) ==14107== by 0x1BC73D12: KMCommand::qt_invoke(int, QUObject*) (kmcommands.moc:147) ==14107== by 0x1BC74062: KMMenuCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2436) ==14107== by 0x1BC740B4: KMMoveCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2616) ==14107== by 0x1BC74142: KMDeleteMsgCommand::qt_invoke(int, QUObject*) (kmcommands.moc:2691) ==14107== by 0x1D63D752: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2357) ==14107== by 0x1D995A9F: QSignal::signal(QVariant const&) (moc_qsignal.cpp:100) ==14107== by 0x1D65AF5E: QSignal::activate() (qsignal.cpp:212) ==14107== by 0x1D662482: QSingleShotTimer::event(QEvent*) (qtimer.cpp:277) ==14107== by 0x1D5DA9D2: QApplication::internalNotify(QObject*, QEvent*) (qapplication.cpp:2635) ==14107== by 0x1D5D9E8F: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:2358) ==14107== by 0x1D0FA7F9: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:549) ==14107== by 0x1D570396: QApplication::sendEvent(QObject*, QEvent*) (qapplication.h:491) ==14107== by 0x1D5C8BE1: QEventLoop::activateTimers() (qeventloop_unix.cpp:558) ==14107== by 0x1D582114: QEventLoop::processEvents(unsigned) (qeventloop_x11.cpp:389) ==14107== by 0x1D5EEC0D: QEventLoop::enterLoop() (qeventloop.cpp:198) ==14107== by 0x1D5EEB29: QEventLoop::exec() (qeventloop.cpp:145) ==14107== by 0x1D5DAB52: QApplication::exec() (qapplication.cpp:2758) ==14107== by 0x804ACCF: main (kapplication.h:218) ASSERT: "!transferInProgress( serNum )" in messageproperty.cpp (219) As promised, here is a backtrace from my system (CVS HEAD, 27.02.2005): Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1106005536 (LWP 20091)] [KCrash handler] #7 0x00000000 in ?? () #8 0x428b3265 in KMail::CachedImapJob::slotPutMessageInfoData ( this=0x9649df8, job=0xa0fcd00, data=@0xaddc0c0) at cachedimapjob.cpp:430 #9 0x428b54e2 in KMail::CachedImapJob::qt_invoke (this=0x9649df8, _id=9, _o=0xbfffe3b0) at qucom_p.h:312 #10 0x415dc31e in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #11 0x40b407ec in KIO::Job::infoMessage (this=0x9462470, t0=0x9462470, t1=@0x83b5e30) at jobclasses.moc:183 #12 0x40b40830 in KIO::SimpleJob::slotInfoMessage (this=0xa0fcd00, msg=@0x83b5e30) at job.cpp:564 #13 0x40b46a40 in KIO::SimpleJob::qt_invoke (this=0x9462470, _id=9, _o=0xbfffe510) at qucom_p.h:449 #14 0x40b46acc in KIO::TransferJob::qt_invoke (this=0x9462470, _id=9, _o=0xbfffe510) at jobclasses.moc:1061 #15 0x415dc31e in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #16 0x415dc60d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #17 0x40b2d30b in KIO::SlaveInterface::infoMessage (this=0x8afedd8, t0=@0xbfffe670) at qmetaobject.h:261 #18 0x40b3117e in KIO::SlaveInterface::dispatch (this=0x8afedd8, _cmd=26, rawdata=@0xbfffe840) at slaveinterface.cpp:369 #19 0x40b318cd in KIO::SlaveInterface::dispatch (this=0x8afedd8) at slaveinterface.cpp:173 #20 0x40b2965e in KIO::Slave::gotInput (this=0x8afedd8) at slave.cpp:300 #21 0x40b2cddc in KIO::Slave::qt_invoke (this=0x8afedd8, _id=4, _o=0xbfffe9c0) at slave.moc:113 #22 0x415dc31e in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #23 0x415dc94d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #24 0x4192ef30 in QSocketNotifier::activated () from /usr/lib/qt3/lib/libqt-mt.so.3 #25 0x415fbf90 in QSocketNotifier::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #26 0x41579baf in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #27 0x4157b773 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0x4111a59a in KApplication::notify (this=0xbffff000, receiver=0x8a86978, event=0xbfffedc0) at kapplication.cpp:549 #29 0x4156dd26 in QEventLoop::activateSocketNotifiers () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0x41527112 in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0x41591b41 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #32 0x41591986 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0x4157b63f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #34 0x08059122 in main (argc=1, argv=0xbffff284) at main.cpp:156 I have seen a lot of crashes when another mail user agent is deleting email, and then when kmail is asked to do something about a deleted email (even just view them) without doing a full sync first - it just crashes. This happens to me in normal (uncached) imap - I wonder if this is related > I have seen a lot of crashes when another mail user agent is
> deleting email, and then when kmail is asked to do something about a
> deleted email (even just view them) without doing a full sync first - it
> just crashes. This happens to me in normal (uncached) imap - I wonder if
> this is related
It's not related AFAIK. It may depend on your settings for your IMAP account
(e.g. load on demand enabled?). Anyway, it should be fixed in KDE 3.4, at
least I haven't got such a crash for a long time when using KMail from CVS
(with online IMAP - this report is a bout disconnected IMAP though).
*** Bug 102131 has been marked as a duplicate of this bug. *** I don't get a crash with HEAD. Can you reproduce this? On Monday 23 May 2005 15:47, Carsten Burghardt wrote:
> ------- I don't get a crash with HEAD. Can you reproduce this?
Yes I had it quite recently.
On Monday 23 May 2005 21:50, George Staikos wrote: > > ------- I don't get a crash with HEAD. Can you reproduce this? > > Yes I had it quite recently. Can you valgrind it with HEAD? Would be great :-) > Can you valgrind it with HEAD? Would be great :-)
Probably not for a little while. I think the bug was clear though - it was
a race where a deleted pointer was held elsewhere.
> Probably not for a little while. I think the bug was clear though - it
> was
> a race where a deleted pointer was held elsewhere.
Right. And I'm trying to find this "elsewhere".
*** Bug 123945 has been marked as a duplicate of this bug. *** *** Bug 128319 has been marked as a duplicate of this bug. *** *** Bug 104205 has been marked as a duplicate of this bug. *** *** Bug 108300 has been marked as a duplicate of this bug. *** *** Bug 132206 has been marked as a duplicate of this bug. *** I cannot reproduce this bug in 1.10.1. I moved 350 messages to a trash folder on the dimap server. During the Trash Synchronization while kmail was performing a scheduled sync. I moved another 150 messages from the inbox to trash. There was no crash, and the 150 messages where properly synchronized at the next interval. I tried the following with kmail 1.10.3: -Moved a bunch of messages to the trash folder -during upload of the messages in trash folder, i deleted the messages No crash occured here. I assume this is fixed now. |