http://bugzilla.meego.com/show_bug.cgi?id=716 Summary: syncevo-dbus-server freezes when backend is bogus Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: enhancement Priority: Medium Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=8384 Description From jku 2009-12-02 02:04:19 PST (-) [reply] This may well be a bug in libecal, but you'll probably know better... After a sync, I opened the service list (so GetConfig worked), clicked Save (so StartSession and possibly Session.SetConfig were started). I'm not 100% sure which one was the last successful call, but at around that point syncevo-dbus-server hung (no response in at least 5 minutes) and had to be killed. Backtrace: #0 0xb7f2f424 in __kernel_vsyscall () #1 0xb79880a5 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0xb7e46843 in e_flag_wait (flag=0xa2872c0) at e-flag.c:120 #3 0xb7e7c6d7 in open_calendar (ecal=0x9dc5650, only_if_exists=<value optimized out>, error=0xbfb370e4, status=0xbfb37078, needs_auth=0) at e-cal.c:1747 #4 0xb7e7cd0a in e_cal_open (ecal=0x9dc5650, only_if_exists=1, error=0xbfb370e4) at e-cal.c:1784 #5 0x081ca583 in SyncEvo::EvolutionCalendarSource::open (this=0xb4903280) at EvolutionCalendarSource.cpp:197 #6 0x081578fe in ReadOperations::checkSource (this=0xbfb372cc, sourceName=...) at syncevo-dbus-server.cpp:1306 #7 0x08197cbc in DBusServer::checkSource (this=0xbfb37774, configName=..., sourceName=...) at syncevo-dbus-server.cpp:334 #8 0x08177588 in boost::_mfi::mf2<void, DBusServer, std::string const&, std::string const&>::operator() (this=0x9a90b84, p=0xbfb37774, a1=..., a2=...) at /usr/include/boost/bind/mem_fn_template.hpp:274 #9 0x081775f8 in boost::_bi::list3<boost::_bi::value<DBusServer*>, boost::arg<1>, boost::arg<2> >::operator()<boost::_mfi::mf2<void, DBusServer, std::string const&, std::string const&>, boost::_bi::list2<std::string const&, std::string const&> > (this=0x9a90b8c, f=..., a=...) at /usr/include/boost/bind/bind.hpp:385 #10 0x0817764b in boost::_bi::bind_t<void, boost::_mfi::mf2<void, DBusServer, std::string const&, std::string const&>, boost::_bi::list3<boost::_bi::value<DBusServer*>, boost::arg<1>, boost::arg<2> (this=0x9a90b84, a1=..., a2=...) at /usr/include/boost/bind/bind_template.hpp:102 #11 0x08177672 in boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void, boost::_mfi::mf2<void, DBusServer, std::string const&, std::string const&>, boost::_bi::list3<boost::_bi::value<DBusServer*>, boost::arg<1>, boost::arg<2> function_obj_ptr=..., a0=..., a1=...) at /usr/include/boost/function/function_template.hpp:153 #12 0x0818d245 in boost::function2<void, std::string const&, std::string const&>::operator() (this=0x9a90b80, a0=..., a1=...) at /usr/include/boost/function/function_template.hpp:1013 #13 0x08198808 in MakeMethodEntry<boost::function<void ()(std::string const&, std::string const&)> >::methodFunction(DBusConnection*, DBusMessage*, void*) ( conn=0x9a8e898, msg=0x9d31600, data=0x9a90b80) at ./gdbus/gdbus-cxx-bridge.h:3569 #14 0x081b56c8 in handle_message (connection=0x9a8e898, message=0x9d31600, user_data=0x9a90de0) at object.c:617 #15 0xb7eee695 in ?? () from /lib/libdbus-1.so.3 #16 0xb7edfdc4 in dbus_connection_dispatch () from /lib/libdbus-1.so.3 #17 0x081b3c58 in queue_dispatch (source=0x9a8ee78, callback=0, user_data=0x0) at mainloop.c:90 #18 0xb766de98 in g_main_dispatch (context=0x9a8d278) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:1960 #19 IA__g_main_context_dispatch (context=0x9a8d278) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2513 #20 0xb7671623 in g_main_context_iterate (context=0x9a8d278, block=1, dispatch=1, self=0x9a8c7a8) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2591 #21 0xb7671aea in IA__g_main_loop_run (loop=0x9a8d1e8) at /build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/glib/gmain.c:2799 #22 0x0815f116 in DBusServer::run (this=0xbfb37774) at syncevo-dbus-server.cpp:2743 #23 0x08168100 in main (argc=1, argv=0xbfb378a4) at syncevo-dbus-server.cpp:2956 ------- Comment #1 From pohly 2009-12-02 04:29:25 PST (-) [reply] ------- (In reply to comment #0) This very much looks like a but in libecal. There's hardly anything that a caller can do wrong when calling e_cal_open(). Can you reproduce it? If so, please use "thread apply all bt" to get stack backtraces. libecal uses multithreading internally. Also check whether evolution-data-server has crashed. That is a know problem, because all synchronous ecal/ebook calls hang in that case with Bonobo-based EDS. I've tried various approaches of dealing with this in SyncEvolution over time, but it all boiled down to one thing: if EDS or ecal/ebook fail in this way, the process pretty much has to be restarted. I'm not sure how to do that with syncevo-dbus-server. A watch dog inside the main process which does an exec() of itself? Putting each backend into its own process and use IPC with timeouts? Note that the "own process" approach might also become necessary at some point anyway, once we have backends with conflicting libraries. Not the case right now. ------- Comment #2 From jku 2009-12-02 05:18:24 PST (-) [reply] ------- (In reply to comment #1) I think the bonobo explanation may be right: this was on Debian testing and I've seen that bonobo bug before here. I just tried Tasks and surprise surprise, it doesn't get anything from eds... It does seem like a lot of work for this, I've understood that bonobo-eds is basically end-of-lifed. I marked this major because I thought this might happen on moblin, and it seems it doesn't. I don't think this warrants major work, I'm fine with waiting for Bonobo to go away and expecting EDS to work in future... ------- Comment #3 From pohly 2009-12-02 05:52:33 PST (-) [reply] ------- (In reply to comment #2) It'll be around in distros for several more years :-/ "expecting EDS to work in future" - always the optimist, aren't you? Well, knock on wood. I agree that we don't have to do anything right away. However, there's always the risk that a bug in one of the backends or one of libraries used by backends break syncevo-dbus-server badly, so I don't want to revisit this topic again later. ------- Comment #4 From yongsheng zhu 2009-12-02 17:04:45 PST (-) [reply] ------- We also encounter the same kind of problem. There is no response from evolution-data-server and syncevolution is always waiting. Is it possbile to add a workaround for this kind of error, such as a timeout mechanism? For a user, if the application is always running without any response or information, it is a really boring thing. ------- Comment #5 From pohly 2009-12-02 22:19:16 PST (-) [reply] ------- (In reply to comment #4) In which version of EDS? On your personal machine(s) or the nightly testing? Jussi, our main testing runs on Debian testing, using 2.26.3 at the moment. It does hang occasionally, but not that frequently either. How often do you see this? ------- Comment #6 From yongsheng zhu 2009-12-02 22:49:34 PST (-) [reply] ------- evolution-data-server 2.28.1. It's on Ubuntun 9.10, a personal machine of one my team member. He is using syncevolution to do syncs. The default database of contacts is UbuntuOne, so the syncevoution is always hanging up and no any message(also many minutes). That's very confusing for users. After changing default database to 'personal', it is correct now. ------- Comment #7 From jku 2009-12-02 23:24:32 PST (-) [reply] ------- (In reply to comment #5) > (In reply to comment #4) > > > > Jussi, our main testing runs on Debian testing, using 2.26.3 at the moment. It > does hang occasionally, but not that frequently either. How often do you see > this? This was the first time for syncevolution. But I've seen EDS block like this twice in the last three months. ------- Comment #8 From pohly 2009-12-03 02:02:03 PST (-) [reply] ------- (In reply to comment #6) > > evolution-data-server 2.28.1. It's on Ubuntun 9.10, a personal machine of one > my team member. He is using syncevolution to do syncs. The default database of > contacts is UbuntuOne, so the syncevoution is always hanging up The syncevolution command line does report an error (bug #7877). A workaround is in 1.0 alpha and will be in 0.9.2. That's for the sync-UI in 0.9.1, right? I doubt that the syncevo-dbus-server really hangs, but rather the sync-UI probably fails to report this particular kind of failure. Jussi just brought up a related question on the mailing list ("is there a sync report in all cases"). In other words, I think your colleague is not suffering from this particular issue (crash of EDS and/or blocking ecal call). ------- Comment #9 From jku 2010-04-07 03:24:39 PST (-) [reply] ------- Created an attachment (id=4673) --> (http://bugzilla.meego.com/attachment.cgi?id=4673) [details] syncevo-dbus-server backtrace (In reply to comment #8) I think I just reproduced that... It's slightly different backtrace, but it's still e_cal_open() called from from DBusServer::checkSource() taking forever. -- Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.