I was experimenting with egroupware and I got this crash when I closed korganizer: Application: KOrganizer (korganizer), signal SIGABRT 0x00007f6efd5d70e1 in nanosleep () from /lib/libc.so.6 [Current thread is 0 (LWP 3085)] Thread 2 (Thread 0x40bf8950 (LWP 3088)): #0 0x00007f6f00a46fad in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f6f00cc8d63 in QWaitConditionPrivate::wait (this=0x18dc460, time=30000) at thread/qwaitcondition_unix.cpp:86 #2 0x00007f6f00cc88d6 in QWaitCondition::wait (this=0x18dc398, mutex=0x18dc390, time=30000) at thread/qwaitcondition_unix.cpp:160 #3 0x00007f6f00cbc3b9 in QThreadPoolThread::run (this=0x18c4a10) at concurrent/qthreadpool.cpp:141 #4 0x00007f6f00cc852e in QThreadPrivate::start (arg=0x18c4a10) at thread/qthread_unix.cpp:190 #5 0x00007f6f00a42fc7 in start_thread () from /lib/libpthread.so.0 #6 0x00007f6efd6087cd in clone () from /lib/libc.so.6 #7 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f6f03210780 (LWP 3085)): [KCrash Handler] #5 0x00007f6efd56aef5 in raise () from /lib/libc.so.6 #6 0x00007f6efd56c413 in abort () from /lib/libc.so.6 #7 0x00007f6f00cbea21 in qt_message_output (msgType=QtFatalMsg, buf=0x7fff0b34ba70 "Fatal Error: Accessed global static 'KProtocolManagerPrivate *kProtocolManagerPrivate()' after destruction. Defined at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/kprotocolmanager.cpp:64") at global/qglobal.cpp:2061 #8 0x00007f6f00cbeb30 in qFatal (msg=0x7f6eff42f4f0 "Fatal Error: Accessed global static '%s *%s()' after destruction. Defined at %s:%d") at global/qglobal.cpp:2263 #9 0x00007f6eff34893c in operator-> (this=0x7f6eff6be4d8) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/kprotocolmanager.cpp:64 #10 0x00007f6eff348a1b in operator KProtocolManagerPrivate* (this=0x7f6eff6be4d8) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/kprotocolmanager.cpp:64 #11 0x00007f6eff34a6ee in KProtocolManager::slaveProtocol (url=@0x1a8e108, proxy=@0x7fff0b34dd98) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/kprotocolmanager.cpp:338 #12 0x00007f6eff379022 in KIO::SchedulerPrivate::doJob (this=0x18c17c0, job=0x1a5d5d0) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/scheduler.cpp:368 #13 0x00007f6eff379ef4 in KIO::Scheduler::doJob (job=0x1a5d5d0) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/scheduler.cpp:250 #14 0x00007f6eff2e7725 in KIO::SimpleJobPrivate::simpleJobInit (this=0x1a8e070) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/job.cpp:316 #15 0x00007f6eff2edbc4 in SimpleJob (this=0x1a5d5d0, dd=@0x1a8e070) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/job.cpp:302 #16 0x00007f6eff2ee82b in TransferJob (this=0x1a5d5d0, dd=@0x1a8e070) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/job.cpp:905 #17 0x00007f6eff2f4e8a in KIO::TransferJobPrivate::newJob (url=@0x7fff0b34df50, command=77, packedArgs=@0x7fff0b34df40, _staticData=@0x7fff0b34e040, flags={i = 188014496}) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/job_p.h:255 #18 0x00007f6eff2f17fd in KIO::http_post (url=@0x7fff0b34e0a0, postData=@0x7fff0b34e040, flags={i = 188014736}) at /home/gkiagia/kde/src/KDE/kdelibs/kio/kio/job.cpp:1419 #19 0x00007f6ef296fad1 in KXMLRPC::Query::call (this=0x1bf7f20, server=@0x7fff0b34e1d0, method=@0x7fff0b34e320, args=@0x7fff0b34e240, userAgent=@0x1b73c70) at /home/gkiagia/kde/src/KDE/kdepim/kresources/egroupware/xmlrpciface.cpp:75 #20 0x00007f6ef29700a3 in KXMLRPC::Server::call (this=0x1b73c50, method=@0x7fff0b34e320, args=@0x7fff0b34e240, msgObj=0x1a4a980, messageSlot=0x7f6ef2983a80 "1logoutFinished( const QList<QVariant>&, const QVariant& )", faultObj=0x1a4a980, faultSlot=0x7f6ef2983ac0 "1fault( int, const QString&, const QVariant& )", id=@0x7fff0b34e300) at /home/gkiagia/kde/src/KDE/kdepim/kresources/egroupware/xmlrpciface.cpp:373 #21 0x00007f6ef297058e in KXMLRPC::Server::call (this=0x1b73c50, method=@0x7fff0b34e320, arg=@0x7fff0b34e310, msgObj=0x1a4a980, messageSlot=0x7f6ef2983a80 "1logoutFinished( const QList<QVariant>&, const QVariant& )", faultObj=0x1a4a980, faultSlot=0x7f6ef2983ac0 "1fault( int, const QString&, const QVariant& )", id=@0x7fff0b34e300) at /home/gkiagia/kde/src/KDE/kdepim/kresources/egroupware/xmlrpciface.cpp:383 #22 0x00007f6ef2977c7b in KCal::ResourceXMLRPC::doClose (this=0x1a4a980) at /home/gkiagia/kde/src/KDE/kdepim/kresources/egroupware/kcal_resourcexmlrpc.cpp:212 #23 0x00007f6f02a315a0 in KRES::Resource::close (this=0x1a4a980) at /home/gkiagia/kde/src/KDE/kdepimlibs/kresources/resource.cpp:141 #24 0x00007f6efef8d03a in KCal::CalendarResources::close (this=0x1a3cc60) at /home/gkiagia/kde/src/KDE/kdepimlibs/kcal/calendarresources.cpp:315 #25 0x00007f6efef8d339 in ~CalendarResources (this=0x1a3cc60) at /home/gkiagia/kde/src/KDE/kdepimlibs/kcal/calendarresources.cpp:225 #26 0x000000000040e0af in ~StdCalendar (this=0x1a3cc60) at /home/gkiagia/kde/src/KDE/kdepim/korganizer/stdcalendar.cpp:109 #27 0x000000000040f3a2 in K3StaticDeleter<KOrg::StdCalendar>::destructObject (this=0x613c20) at /home/gkiagia/kde/include/k3staticdeleter.h:174 #28 0x00007f6f01cd8dcc in K3StaticDeleterPrivate::deleteStaticDeleters () at /home/gkiagia/kde/src/KDE/kdelibs/kde3support/kdecore/k3staticdeleter.cpp:56 #29 0x00007f6f00db4914 in qt_call_post_routines () at kernel/qcoreapplication.cpp:165 #30 0x00007f6eff8a3ba8 in ~QApplication (this=0x7fff0b34e6e0) at kernel/qapplication.cpp:945 #31 0x00007f6f021a9a09 in ~KApplication (this=0x7fff0b34e6e0) at /home/gkiagia/kde/src/KDE/kdelibs/kdeui/kernel/kapplication.cpp:940 #32 0x00007f6f021b10a6 in ~KUniqueApplication (this=0x7fff0b34e6e0) at /home/gkiagia/kde/src/KDE/kdelibs/kdeui/kernel/kuniqueapplication.cpp:372 #33 0x000000000040de18 in ~PimApplication (this=0x7fff0b34e6e0) at /home/gkiagia/kde/src/KDE/kdepim/libkdepim/pimapplication.h:37 #34 0x000000000040db68 in ~KOrganizerApp (this=0x7fff0b34e6e0) at /home/gkiagia/kde/src/KDE/kdepim/korganizer/koapp.cpp:69 #35 0x000000000040b3ac in main (argc=1, argv=0x7fff0b34e888) at /home/gkiagia/kde/src/KDE/kdepim/korganizer/main.cpp:58
Forgot to mention, this is svn trunk r865463.
Intelligent destructors are not good design, this is another proof of it. Somehow the application should properly close the resources (which is where kio call would be made) before exiting (and that means, before KApplication itself is destroyed -- it's far too late then). But I can see how this doesn't go well with the StdCalendar singleton. Hmm, maybe delete StdCalendar in main, just before the app instance goes out of scope?
*** Bug 179373 has been marked as a duplicate of this bug. ***
*** Bug 181649 has been marked as a duplicate of this bug. ***
*** Bug 181958 has been marked as a duplicate of this bug. ***
*** Bug 181953 has been marked as a duplicate of this bug. ***
dfaure wrote: > But I can see how this doesn't go well with the StdCalendar singleton. Hmm, > maybe delete StdCalendar in main, just before the app instance goes out of > scope? Like this? int result = app.exec(); delete KOrg::StdCalendar::self(); return result; } Indeed, it fixes the crash.
Something like this (ideally, only if it exists -- it would be useless to create it just in order to destroy it ;-). I don't work on korganizer myself, hopefully a korganizer developer will react to this patch, otherwise sent it to the kdepim list.
It isn't exactly egroupware's destructor, it's doClose(), which creates a http KIO job to call the xmlrpc logout method. If we add that "delete StdCalendar" won't the job get interrupted and killed? Couldn't we just stop sending the "logout" at close? Seems to work fine here. Anyone knows if it's optional? Or maybe make this call synchronous?
*** Bug 188718 has been marked as a duplicate of this bug. ***
*** Bug 204939 has been marked as a duplicate of this bug. ***
*** Bug 208490 has been marked as a duplicate of this bug. ***
The current recommendation from EGroupware is to use GroupDAV. It's the only actively developed access method to EGroupware supported by KDE! Ralf
*** Bug 214330 has been marked as a duplicate of this bug. ***
*** Bug 216537 has been marked as a duplicate of this bug. ***
Any chance we can get that fixed? GroupDav deoes not seem to work at all, so right now there is no way to use KOrganizer as eGroupWare client.
(In reply to comment #16) > Any chance we can get that fixed? > GroupDav deoes not seem to work at all, so right now there is no way to use > KOrganizer as eGroupWare client. ++10000
(In reply to comment #16) > Any chance we can get that fixed? > GroupDav deoes not seem to work at all, so right now there is no way to use > KOrganizer as eGroupWare client. A new groupdav resource ( akonadi based ) was written from scratch and it works fine.