On Thu, Nov 22, 2012 at 12:05:26 +0100, Patrick Ohly wrote:
> On Thu, 2012-11-22 at 11:12 +0100, [email protected]
> wrote:
> > On Thu, Nov 22, 2012 at 11:00:56 +0100, [email protected]
> > 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
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
