On Thu, Nov 22, 2012 at 12:05:26 +0100, Patrick Ohly wrote:
On Thu, 2012-11-22 at 11:12 +0100,
tino.keitel+syncevolution(a)tikei.de
wrote:
> On Thu, Nov 22, 2012 at 11:00:56 +0100, tino.keitel+syncevolution(a)tikei.de wrote:
> > Hi,
> >
> > I tried the following:
> >
> > syncevolution --configure autoSyncInterval=30 eazy
> >
> > This command does not return. According to strace, it seems to wait
> > forever in poll().
> >
> > Adding --daemon=no to the options does not hang.
> >
> > Subsequent sync runs will also hang.
> >
> > This happens with 1.3.1 with commit
> > d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
>
> It also happens with 1.2.99.1 from Debian Sid. I noticed that the
> syncevo-dbus-helper process needs to be killed with SIGKILL after this,
> SIGTERM won't suffice.
I can't reproduce that here, using 1.3.1.
Is there perhaps a sync running while you invoke the command line?
Executing the command line will have to wait until syncing is complete.
None that I know of.
To collect more information, please kill syncevo-dbus-server
and run it manually as
SYNCEVOLUTION_DEBUG=1 /usr/libexec/syncevo-dbus-server
The output is attached.
Then in another shell try to set autoSyncInterval. That should show what
the server is waiting for.
Then when the helper gets stuck, what is the full stack backtrace? Just
poll inside g_main_loop_run()?
It seems so:
(gdb) run
Starting program: /usr/bin/syncevolution --configure
autoSyncInterval=3M eazy
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecc37700 (LWP 30483)]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff5345e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff5345e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff6212624 in ?? () from
#/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff6212a82 in g_main_loop_run ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00000000004245b6 in SyncEvo::RemoteDBusServer::execute (
this=this@entry=0x7fffffffdee0, args=..., peer=...,
runSync=runSync@entry=false) at src/syncevolution.cpp:768
#4 0x000000000041e54d in SyncEvo::main (argc=4, argv=<optimized out>)
at src/syncevolution.cpp:500
(gdb)
The stack of syncevo-dbus-helper looks like this:
#0 0x00007f576b1a1e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f57685b7d30 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007f57685b6bfd in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007f57685a1904 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007f57685a29fa in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007f57660675aa in ?? ()
from /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0
#6 0x00007f576628e787 in SyncEvo::GNOMESavePasswordSlot (keyring=...,
passwordName=..., password=..., key=...)
at src/backends/gnome/GNOMEPlatform.cpp:118
So maybe it prompts for some password. I'll see if I get home. :-)
Regards,
Tino