On Mon, Dec 19, 2011 at 12:08 PM, Patrick Ohly <patrick.o...@intel.com> wrote: > On Mo, 2011-12-19 at 10:57 +0100, Chris Kühl wrote: >> On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <patrick.o...@intel.com> 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 (?).
Yes this is what the libdbus docs tell us. > > 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. > I was wondering why these are all private. Now I've at least got a hint. > So perhaps the parameter for that can be removed and made a static > choice in the dbus_get_bus_connection() implementations? > I'm about half way through test-dbus.py and things are looking fine using the singleton connection acquired by g_bus_get_sync(). so, if my interpretation of what you're saying is correct, we can just remove the unshared (btw, using a negative for a boolean value is confusing.) option and make the gio gdbus always be a shared, singleton connection and the libdbus connection always be private. Correct? Cheers, Chris >> > 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. > Hmm. I get SyncEvolution 1.2.1+20111218+SE+3f4f71a (pre-release) when running that on my Debian Testing install. But we have had different results in the past on Deban Testing so I'm becoming less and less surprised by this. Cheers, Chris _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
