11:48 a.m.
Hi All,
I just thought I'd post about some issues we're seeing with the beta3
on Fedora 13 and rawhide.
Firstly syncevolution doesn't compile against the latest evolution
2.31.x releases. I believe this is due to some changes in libcamel in
preparation for evolution 3.0.
On Fedora 13 we're seeing a fairly regular crash in dbus_error_is_set
[1], I've had about a dozen or so reports on that so far.
Regards,
Peter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=591786
12:19 p.m.
On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
Firstly syncevolution doesn't compile against the latest
evolution
2.31.x releases. I believe this is due to some changes in libcamel in
preparation for evolution 3.0.
SyncEvolution doesn't include anything from libcamel. Can you quote an
error message?
On Fedora 13 we're seeing a fairly regular crash in
dbus_error_is_set
[1], I've had about a dozen or so reports on that so far.
This is the code:
DBusConnection *g_dbus_setup_bus(DBusBusType type, const char *name,
gboolean unshared,
DBusError *error)
{
DBusConnection *connection;
DBG("type %d name %s error %p", type, name, error);
connection = unshared ? dbus_bus_get_private(type, error) :
dbus_bus_get(type, error);
if (error != NULL) {
if (dbus_error_is_set(error) == TRUE)
return NULL;
}
Looks to me like dbus_get_private() (which is what SyncEvolution uses)
does not set a proper error pointer. valgrind should tell us more. Note
that the mainloop.c:458 line does not quite match the source - confused
debug information?
Can you follow up to this? I don't have a FC 13 installation at hand.
--
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.
12:38 p.m.
On Mon, May 31, 2010 at 1:19 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
> Firstly syncevolution doesn't compile against the latest evolution
> 2.31.x releases. I believe this is due to some changes in libcamel in
> preparation for evolution 3.0.
SyncEvolution doesn't include anything from libcamel. Can you quote an
error message?
Actually on closer look it might be changes in gtk and not evolution.
My bad, sorry.
http://koji.fedoraproject.org/koji/getfile?taskID=2210957&name=build.log
> On Fedora 13 we're seeing a fairly regular crash in
dbus_error_is_set
> [1], I've had about a dozen or so reports on that so far.
This is the code:
DBusConnection *g_dbus_setup_bus(DBusBusType type, const char *name,
gboolean unshared,
DBusError *error)
{
DBusConnection *connection;
DBG("type %d name %s error %p", type, name, error);
connection = unshared ? dbus_bus_get_private(type, error) :
dbus_bus_get(type, error);
if (error != NULL) {
if (dbus_error_is_set(error) == TRUE)
return NULL;
}
Looks to me like dbus_get_private() (which is what SyncEvolution uses)
does not set a proper error pointer. valgrind should tell us more. Note
that the mainloop.c:458 line does not quite match the source - confused
debug information?
Can you follow up to this? I don't have a FC 13 installation at hand.
I'll do so as best as I can. The following crash dumps look to be the
most complete. If they don't have what's needed I'll look at what I
can do to get you a more complete one.
https://bugzilla.redhat.com/attachment.cgi?id=418008
https://bugzilla.redhat.com/attachment.cgi?id=418102
https://bugzilla.redhat.com/attachment.cgi?id=418228
Peter
8:14 p.m.
On Mon, 2010-05-31 at 13:38 +0100, Peter Robinson wrote:
On Mon, May 31, 2010 at 1:19 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
>> Firstly syncevolution doesn't compile against the latest evolution
>> 2.31.x releases. I believe this is due to some changes in libcamel in
>> preparation for evolution 3.0.
>
> SyncEvolution doesn't include anything from libcamel. Can you quote an
> error message?
Actually on closer look it might be changes in gtk and not evolution.
My bad, sorry.
http://koji.fedoraproject.org/koji/getfile?taskID=2210957&name=build.log
That points towards unistd.h:
sync-ui.c:2905: error: conflicting types for 'sync'
/usr/include/unistd.h:986: note: previous declaration of 'sync' was here
What is in line 986?
Please check the following patch. If it works, I'll include this in 1.0:
diff --git a/src/gtk-ui/sync-ui.c b/src/gtk-ui/sync-ui.c
index 40c9ceb..b693ec7 100644
--- a/src/gtk-ui/sync-ui.c
+++ b/src/gtk-ui/sync-ui.c
@@ -2928,7 +2928,7 @@ save_config (app_data *data, SyncevoSession
*session)
}
static void
-sync (operation_data *op_data, SyncevoSession *session)
+do_sync (operation_data *op_data, SyncevoSession *session)
{
GHashTable *source_modes;
GHashTableIter iter;
@@ -2998,7 +2998,7 @@ set_config_for_sync_cb (SyncevoSession *session,
return;
}
- sync (op_data, session);
+ do_sync (op_data, session);
}
static void
I'll do so as best as I can. The following crash dumps look to be
the
most complete. If they don't have what's needed I'll look at what I
can do to get you a more complete one.
https://bugzilla.redhat.com/attachment.cgi?id=418008
https://bugzilla.redhat.com/attachment.cgi?id=418102
https://bugzilla.redhat.com/attachment.cgi?id=418228
All of that confirms that the "error" pointer wasn't set correctly. But
why? This needs to be checked with valgrind and gdb and looking at the
dbus library call prior to the failure.
--
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.
6:22 a.m.
On Mon, 2010-05-31 at 21:14 +0100, Patrick Ohly wrote:
On Mon, 2010-05-31 at 13:38 +0100, Peter Robinson wrote:
> On Mon, May 31, 2010 at 1:19 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
> >> Firstly syncevolution doesn't compile against the latest evolution
> >> 2.31.x releases. I believe this is due to some changes in libcamel in
> >> preparation for evolution 3.0.
> >
> > SyncEvolution doesn't include anything from libcamel. Can you quote an
> > error message?
>
> Actually on closer look it might be changes in gtk and not evolution.
> My bad, sorry.
>
> http://koji.fedoraproject.org/koji/getfile?taskID=2210957&name=build.log
That points towards unistd.h:
sync-ui.c:2905: error: conflicting types for 'sync'
/usr/include/unistd.h:986: note: previous declaration of 'sync' was here
What is in line 986?
Eh, "void sync(void)" of course. I've applied the patch.
> I'll do so as best as I can. The following crash dumps look
to be the
> most complete. If they don't have what's needed I'll look at what I
> can do to get you a more complete one.
>
> https://bugzilla.redhat.com/attachment.cgi?id=418008
> https://bugzilla.redhat.com/attachment.cgi?id=418102
> https://bugzilla.redhat.com/attachment.cgi?id=418228
All of that confirms that the "error" pointer wasn't set correctly. But
why? This needs to be checked with valgrind and gdb and looking at the
dbus library call prior to the failure.
Any update on that?
Note that what I said earlier about "error" not set is not quite right.
It is wrong in internal_bus_get(), but was still sane in
g_dbus_setup_bus():
#1 0x00000033b800b4f7 in internal_bus_get (type=DBUS_BUS_SESSION,
private=0,
error=0x1) at dbus-bus.c:435
address = <value optimized out>
connection = <value optimized out>
bd = <value optimized out>
address_type = <value optimized out>
__FUNCTION__ = "internal_bus_get"
#2 0x00007f443dd551d1 in g_dbus_setup_bus (type=DBUS_BUS_SYSTEM, name=0x0,
error=0x33b802ec98) at mainloop.c:458
connection = <value optimized out>
This is the source code:
DBusConnection *g_dbus_setup_bus(DBusBusType type, const char *name,
gboolean unshared,
DBusError *error)
{
DBusConnection *connection;
DBG("type %d name %s error %p", type, name, error);
connection = unshared ? dbus_bus_get_private(type, error) :
dbus_bus_get(type, error);
There's really no chance in the C source code to mangle "error". Must
happen inside the compiler generated code or in the dbus functions.
Again, valgrind might show something.
--
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.
2:07 p.m.
On Fri, Jun 4, 2010 at 7:22 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2010-05-31 at 21:14 +0100, Patrick Ohly wrote:
> On Mon, 2010-05-31 at 13:38 +0100, Peter Robinson wrote:
> > On Mon, May 31, 2010 at 1:19 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
> > > On Mon, 2010-05-31 at 12:48 +0100, Peter Robinson wrote:
> > >> Firstly syncevolution doesn't compile against the latest evolution
> > >> 2.31.x releases. I believe this is due to some changes in libcamel in
> > >> preparation for evolution 3.0.
> > >
> > > SyncEvolution doesn't include anything from libcamel. Can you quote an
> > > error message?
> >
> > Actually on closer look it might be changes in gtk and not evolution.
> > My bad, sorry.
> >
> > http://koji.fedoraproject.org/koji/getfile?taskID=2210957&name=build.log
>
> That points towards unistd.h:
>
> sync-ui.c:2905: error: conflicting types for 'sync'
> /usr/include/unistd.h:986: note: previous declaration of 'sync' was
here
>
> What is in line 986?
Eh, "void sync(void)" of course. I've applied the patch.
> > I'll do so as best as I can. The following crash dumps look to be the
> > most complete. If they don't have what's needed I'll look at what I
> > can do to get you a more complete one.
> >
> > https://bugzilla.redhat.com/attachment.cgi?id=418008
> > https://bugzilla.redhat.com/attachment.cgi?id=418102
> > https://bugzilla.redhat.com/attachment.cgi?id=418228
>
> All of that confirms that the "error" pointer wasn't set correctly.
But
> why? This needs to be checked with valgrind and gdb and looking at the
> dbus library call prior to the failure.
Any update on that?
Note that what I said earlier about "error" not set is not quite right.
It is wrong in internal_bus_get(), but was still sane in
g_dbus_setup_bus():
#1 0x00000033b800b4f7 in internal_bus_get (type=DBUS_BUS_SESSION,
private=0,
error=0x1) at dbus-bus.c:435
address = <value optimized out>
connection = <value optimized out>
bd = <value optimized out>
address_type = <value optimized out>
__FUNCTION__ = "internal_bus_get"
#2 0x00007f443dd551d1 in g_dbus_setup_bus (type=DBUS_BUS_SYSTEM, name=0x0,
error=0x33b802ec98) at mainloop.c:458
connection = <value optimized out>
This is the source code:
DBusConnection *g_dbus_setup_bus(DBusBusType type, const char *name,
gboolean unshared,
DBusError *error)
{
DBusConnection *connection;
DBG("type %d name %s error %p", type, name, error);
connection = unshared ? dbus_bus_get_private(type, error) :
dbus_bus_get(type, error);
There's really no chance in the C source code to mangle "error". Must
happen inside the compiler generated code or in the dbus functions.
Again, valgrind might show something.
Sorry about the delay on this, its been somewhat busy of late!
The remaining error in 1.0 seems to be the dbus_error_is_set crash
which stops it from running at all on Fedora 13. I pushed out 1.0 to
updates-testing yesterday and already have half a dozen dupes. The bug
with all the dupes is below, let me know if you need more information
and I'll try and sort it out.
Peter
https://bugzilla.redhat.com/show_bug.cgi?id=606647
3:13 p.m.
On Tue, 2010-06-22 at 15:07 +0100, Peter Robinson wrote:
> This is the source code:
>
> DBusConnection *g_dbus_setup_bus(DBusBusType type, const char *name,
> gboolean unshared,
> DBusError *error)
> {
> DBusConnection *connection;
>
> DBG("type %d name %s error %p", type, name, error);
>
> connection = unshared ? dbus_bus_get_private(type, error) :
> dbus_bus_get(type, error);
>
> There's really no chance in the C source code to mangle "error". Must
> happen inside the compiler generated code or in the dbus functions.
> Again, valgrind might show something.
Sorry about the delay on this, its been somewhat busy of late!
The remaining error in 1.0 seems to be the dbus_error_is_set crash
which stops it from running at all on Fedora 13. I pushed out 1.0 to
updates-testing yesterday and already have half a dozen dupes. The bug
with all the dupes is below, let me know if you need more information
and I'll try and sort it out.
Are you able to reproduce the problem? Can you
run /usr/libexec/syncevo-dbus-server under valgrind, then cause it to
crash by also starting the command line?
My hope is that the valgrind output shows a bit more than the stack back
traces that are currently in the bug reports.
--
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.
4237
days inactive
4259
days old
syncevolution@synevolution.org
6 comments
2 participants
participants (2)
-
Patrick Ohly -
Peter Robinson