7:35 p.m.
Hi,
with sync-ui from syncevolution 1.3.2 in Debian Sid I get the following
segmentation fault:
** (sync-ui:27623): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/syncevolution
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1 0x00007ffff6655c69 in g_str_has_prefix (str=str@entry=0x558efa70 <Address
0x558efa70 out of bounds>,
prefix=prefix@entry=0x7ffff63eabc5 "queueing") at
/tmp/buildd/glib2.0-2.36.4/./glib/gstrfuncs.c:2783
#2 0x00007ffff63e710e in syncevo_session_status_from_string (status_str=0x558efa70
<Address 0x558efa70 out of bounds>)
at src/dbus/glib/syncevo-dbus-types.c:200
#3 0x00007ffff63e9104 in status_changed_cb (proxy=<optimized out>,
status=<optimized out>, error_code=0, source_statuses=0x555555886e40,
session=0x7fffe0005d80) at src/dbus/glib/syncevo-session.c:82
#4 0x00007ffff6b4fa84 in marshal_dbus_message_to_g_marshaller (closure=0x555555929450,
return_value=0x0, n_param_values=<optimized out>,
param_values=<optimized out>, invocation_hint=0x7fffffffdc00, marshal_data=0x0)
at dbus-gproxy.c:1736
#5 0x00007ffff68fdf28 in g_closure_invoke (closure=0x555555929450, return_value=0x0,
n_param_values=3, param_values=0x7fffffffdc60,
invocation_hint=0x7fffffffdc00) at
/tmp/buildd/glib2.0-2.36.4/./gobject/gclosure.c:777
#6 0x00007ffff690eedd in signal_emit_unlocked_R (node=node@entry=0x5555557bc5d0,
detail=detail@entry=1020,
instance=instance@entry=0x7fffe0002b20, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffdc60) at
/tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3584
#7 0x00007ffff6916ce9 in g_signal_emit_valist (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffde18) at
/tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3328
#8 0x00007ffff6916f32 in g_signal_emit (instance=instance@entry=0x7fffe0002b20,
signal_id=<optimized out>, detail=<optimized out>)
at /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3384
#9 0x00007ffff6b500ea in dbus_g_proxy_emit_remote_signal (message=0x5555557b9950,
proxy=0x7fffe0002b20) at dbus-gproxy.c:1789
#10 dbus_g_proxy_manager_filter (user_data=0x555555813b40, message=0x5555557b9950,
connection=<optimized out>) at dbus-gproxy.c:1356
#11 dbus_g_proxy_manager_filter (connection=<optimized out>, message=0x5555557b9950,
user_data=0x555555813b40) at dbus-gproxy.c:1196
#12 0x00007ffff1b359e6 in dbus_connection_dispatch () from
/lib/x86_64-linux-gnu/libdbus-1.so.3
#13 0x00007ffff6b49765 in message_queue_dispatch (source=source@entry=0x5555557bc110,
callback=<optimized out>, user_data=<optimized out>)
at dbus-gmain.c:90
#14 0x00007ffff6636ea6 in g_main_dispatch (context=0x5555557a8b50) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
#15 g_main_context_dispatch (context=context@entry=0x5555557a8b50) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
#16 0x00007ffff66371f8 in g_main_context_iterate (context=0x5555557a8b50,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
#17 0x00007ffff66375fa in g_main_loop_run (loop=0x555555905930) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
#18 0x00007ffff78cd2e7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#19 0x000055555555b177 in main (argc=<optimized out>, argv=<optimized out>) at
src/gtk-ui/main.c:175
Does that ring any bells?
Regards,
Tino
6:35 a.m.
On Thu, 2013-09-26 at 21:35 +0200, Tino Keitel wrote:
Hi,
with sync-ui from syncevolution 1.3.2 in Debian Sid I get the following
segmentation fault:
** (sync-ui:27623): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/syncevolution
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1 0x00007ffff6655c69 in g_str_has_prefix (str=str@entry=0x558efa70 <Address
0x558efa70 out of bounds>,
prefix=prefix@entry=0x7ffff63eabc5 "queueing") at
/tmp/buildd/glib2.0-2.36.4/./glib/gstrfuncs.c:2783
#2 0x00007ffff63e710e in syncevo_session_status_from_string (status_str=0x558efa70
<Address 0x558efa70 out of bounds>)
at src/dbus/glib/syncevo-dbus-types.c:200
#3 0x00007ffff63e9104 in status_changed_cb (proxy=<optimized out>,
status=<optimized out>, error_code=0, source_statuses=0x555555886e40,
session=0x7fffe0005d80) at src/dbus/glib/syncevo-session.c:82
#4 0x00007ffff6b4fa84 in marshal_dbus_message_to_g_marshaller (closure=0x555555929450,
return_value=0x0, n_param_values=<optimized out>,
param_values=<optimized out>, invocation_hint=0x7fffffffdc00, marshal_data=0x0)
at dbus-gproxy.c:1736
[...]
Does that ring any bells?
Sorry, no.
Looks related to handling a D-Bus message. Can you run sync-ui as
env G_DBUS_DEBUG=message valgrind sync-ui
and check what the last message is? valgrind should give more
information about the crash.
--
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:03 p.m.
On Fri, Sep 27, 2013 at 08:35:10 +0200, Patrick Ohly wrote:
[...]
Looks related to handling a D-Bus message. Can you run sync-ui as
env G_DBUS_DEBUG=message valgrind sync-ui
and check what the last message is? valgrind should give more
information about the crash.
Hi,
attached is the complete output of the above command.
Regards,
Tino
2:50 p.m.
On Fri, 2013-09-27 at 16:03 +0200, tino.keitel+syncevolution(a)tikei.de
wrote:
On Fri, Sep 27, 2013 at 08:35:10 +0200, Patrick Ohly wrote:
[...]
> Looks related to handling a D-Bus message. Can you run sync-ui as
>
> env G_DBUS_DEBUG=message valgrind sync-ui
>
> and check what the last message is? valgrind should give more
> information about the crash.
Hi,
attached is the complete output of the above command.
I need the output when it crashes.
--
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.
7:14 p.m.
On Fri, Sep 27, 2013 at 16:50:01 +0200, Patrick Ohly wrote:
On Fri, 2013-09-27 at 16:03 +0200,
tino.keitel+syncevolution(a)tikei.de
wrote:
> On Fri, Sep 27, 2013 at 08:35:10 +0200, Patrick Ohly wrote:
>
> [...]
>
> > Looks related to handling a D-Bus message. Can you run sync-ui as
> >
> > env G_DBUS_DEBUG=message valgrind sync-ui
> >
> > and check what the last message is? valgrind should give more
> > information about the crash.
>
> Hi,
>
> attached is the complete output of the above command.
I need the output when it crashes.
It doesn't crash when run under valgrind.
Without valgrind, this is the last gdbus message:
========================================================================
GDBus-debug:Message:
<<<< RECEIVED D-Bus message (72 bytes)
Type: method-return
Flags: no-reply-expected
Version: 0
Serial: 6
Headers:
reply-serial -> uint32 6
destination -> ':1.86'
sender -> 'org.freedesktop.DBus'
Body: ()
UNIX File Descriptors:
(none)
** (sync-ui:29770): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/syncevolution
Segmentation fault
Regards,
Tino
6 p.m.
On Fri, 2013-09-27 at 21:14 +0200, Tino Keitel wrote:
On Fri, Sep 27, 2013 at 16:50:01 +0200, Patrick Ohly wrote:
> On Fri, 2013-09-27 at 16:03 +0200, tino.keitel+syncevolution(a)tikei.de
> wrote:
> > On Fri, Sep 27, 2013 at 08:35:10 +0200, Patrick Ohly wrote:
> >
> > [...]
> >
> > > Looks related to handling a D-Bus message. Can you run sync-ui as
> > >
> > > env G_DBUS_DEBUG=message valgrind sync-ui
> > >
> > > and check what the last message is? valgrind should give more
> > > information about the crash.
> >
> > Hi,
> >
> > attached is the complete output of the above command.
>
> I need the output when it crashes.
It doesn't crash when run under valgrind.
Let's backtrace a bit. What steps are necessary to make it crash without
valgrind?
And those same steps do not cause it to crash when running under
valgrind?
--
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.
7:34 p.m.
On Sat, Sep 28, 2013 at 20:00:07 +0200, Patrick Ohly wrote:
[...]
Let's backtrace a bit. What steps are necessary to make it crash
without
valgrind?
I just click on "Sync now" in sync-ui. It segfaults, and if I restart
it as long as the sync is running, it segfaults again without any
further GUI action by the user.
I use the current Debian sid and the packages from
http://tikei.de/syncevolution-1.3.2/
And those same steps do not cause it to crash when running under
valgrind?
Yes.
Regards,
Tino
1:26 p.m.
On Sun, 2013-09-29 at 21:34 +0200, Tino Keitel wrote:
On Sat, Sep 28, 2013 at 20:00:07 +0200, Patrick Ohly wrote:
[...]
> Let's backtrace a bit. What steps are necessary to make it crash without
> valgrind?
I just click on "Sync now" in sync-ui. It segfaults, and if I restart
it as long as the sync is running, it segfaults again without any
further GUI action by the user.
Could it be that no service is selected while running that sync? I was
able to reproduce such a crash in find_updated_source_progress(). Patch
attached.
But that doesn't match your initial stack backtrace at all. Are you
compiling with GTK-2 or GTK-3? If the crash persists, can you recompile
without optimization and capture another stack backtrace?
I use the current Debian sid and the packages from
http://tikei.de/syncevolution-1.3.2/
The crash is independent of the specific version. This has been broken
for a long time.
> And those same steps do not cause it to crash when running
under
> valgrind?
Yes.
Really strange. Perhaps it changes timing so that the method never gets
invoked because the sync completes too quickly.
--
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.
1:39 p.m.
On Mon, Sep 30, 2013 at 15:26:50 +0200, Patrick Ohly wrote:
On Sun, 2013-09-29 at 21:34 +0200, Tino Keitel wrote:
> On Sat, Sep 28, 2013 at 20:00:07 +0200, Patrick Ohly wrote:
>
> [...]
>
> > Let's backtrace a bit. What steps are necessary to make it crash without
> > valgrind?
>
> I just click on "Sync now" in sync-ui. It segfaults, and if I restart
> it as long as the sync is running, it segfaults again without any
> further GUI action by the user.
Could it be that no service is selected while running that sync? I was
able to reproduce such a crash in find_updated_source_progress(). Patch
attached.
The correct service is shown at the top of the window, so I guess that
it is selected.
Btw., when I click on "Change or edit sync service", I get a segfault
with a similar backtrace.
I'll try the attached patch.
But that doesn't match your initial stack backtrace at all. Are you
compiling with GTK-2 or GTK-3?
The build environment uses libgtk2.0-dev.
If the crash persists, can you recompile
without optimization and capture another stack backtrace?
OK, I'll try.
Regards,
Tino
3:09 p.m.
Hi,
meanwhile, I could nail it down to the compiler/linker flags used for
the package build (export DEB_BUILD_MAINT_OPTIONS = hardening=+all).
I'll report back what flag exactly causes the
segfault.
Regards,
Tino
4:03 p.m.
On Mon, Sep 30, 2013 at 17:09:29 +0200, tino.keitel+syncevolution(a)tikei.de wrote:
Hi,
meanwhile, I could nail it down to the compiler/linker flags used for
the package build (export DEB_BUILD_MAINT_OPTIONS = hardening=+all).
I'll report back what flag exactly causes the
segfault.
The segfault happens when I build with -fPIE and link with -fPIE -pie.
As this mainly deals with address space layout, my guess is that this
just unhides another bug.
Regards,
Tino
8:08 p.m.
On Mon, 2013-09-30 at 18:03 +0200, tino.keitel+syncevolution(a)tikei.de
wrote:
On Mon, Sep 30, 2013 at 17:09:29 +0200,
tino.keitel+syncevolution(a)tikei.de wrote:
> Hi,
>
> meanwhile, I could nail it down to the compiler/linker flags used for
> the package build (export DEB_BUILD_MAINT_OPTIONS = hardening=+all).
>
> I'll report back what flag exactly causes the
> segfault.
The segfault happens when I build with -fPIE and link with -fPIE -pie.
As this mainly deals with address space layout, my guess is that this
just unhides another bug.
Bingo! You've found a 64 bit bug in sync-ui. As the other bug, this goes
back to the original development of the UI.
At one point, it passes a string pointer through a 32bit unsigned int,
which only works as long as the memory actually lies in the lower
address range. PIE mode seems to change that such that the conversion
drops significant bits, while running under valgrind changes it back to
"working" again.
I was able to reproduce it with these compile flags. Attached the fix.
--
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.
8:17 a.m.
On Mon, Sep 30, 2013 at 22:08:15 +0200, Patrick Ohly wrote:
On Mon, 2013-09-30 at 18:03 +0200,
tino.keitel+syncevolution(a)tikei.de
wrote:
> On Mon, Sep 30, 2013 at 17:09:29 +0200, tino.keitel+syncevolution(a)tikei.de wrote:
> > Hi,
> >
> > meanwhile, I could nail it down to the compiler/linker flags used for
> > the package build (export DEB_BUILD_MAINT_OPTIONS = hardening=+all).
> >
> > I'll report back what flag exactly causes the
> > segfault.
>
> The segfault happens when I build with -fPIE and link with -fPIE -pie.
> As this mainly deals with address space layout, my guess is that this
> just unhides another bug.
Bingo! You've found a 64 bit bug in sync-ui. As the other bug, this goes
back to the original development of the UI.
At one point, it passes a string pointer through a 32bit unsigned int,
Hi,
thanks, the segmentation fault is now gone.
When looking at the gdb trace, I thought that the "out of bounds"
address looks like there where 16 high bits missing compared to the
other addresses, so I also suspected a wrong pointer usage and the
patch perfectly makes sense.
Regards,
Tino
3189
days inactive
3194
days old
syncevolution@synevolution.org
12 comments
3 participants
participants (3)
-
Patrick Ohly -
Tino Keitel -
tino.keitel+syncevolution＠tikei.de