On Mo, 2011-12-19 at 10:57 +0100, Chris Kühl wrote: > On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <[email protected]> wrote: > > Note that your example code closed the > > connection while the rest of SyncEvolution didn't. This might be > > something that still needs to be fixed. > > > > It seems that this is dependent on how the connection was created. Let > me take a look at this more closely.
Private connections need to be closed, shared must not be closed (?). Note that the libdbus based code uses private connections for everything. I think that this was done to avoid some interoperability issues with EDS using GIO - but memory is hazy on that. Going forward the old-style code should continue to use private connections while the new GIO code can be tested with shared connections. So perhaps the parameter for that can be removed and made a static choice in the dbus_get_bus_connection() implementations? > > While testing that with GDBus GIO I noticed that I get segfaults when > > compiling on Debian Testing and --with-gio-dbus. That happens with and > > without my clean up patches - Chris, can you check that? If you cannot > > reproduce it, then please let me know and I will check it. It's a bit > > strange that I haven't seen that in the nightly testing. > > > > The signal callback seems to get an invalid std::string: > > > > My testing involved running the test-dbus.py script. I guess this > didn't cover all cases. I'll look into this as well. Right, another test-dbus.py run passed fine this weekend. So let me be more precise: a "syncevolution --version" invocation segfaults. This is indeed a gap in the nightly testing. I need to add real tests for syncevolution <-> syncev-dbus-server. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
