On Di, 2011-08-09 at 11:05 +0200, Tobias Hägele wrote:
this error is Back:
> Now,the UI is ok and i can klick to my phone. but I can even change
any
> > settings thrugh the UI (but delete and re create the settings).
"But I can even change" - that sounds like you had a problem, but it
isn't clear to me which one.
How i said in my last mail, i can't change the preferences of the
sync.
While this, the following appears in Valgrind:
#############
valgrind /usr/libexec/syncevo-dbus-server 2>&1 | tee /tmp/valgrind.log
==5424== Memcheck, a memory error detector
==5424== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et
al.
==5424== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright
info
==5424== Command: /usr/libexec/syncevo-dbus-server
==5424==
[INFO] /usr/libexec/syncevo-dbus-server: ready to run
[ERROR] The source 'tasks' is not usable
[ERROR] cannot detach from resource that client is not attached to
[...]
[ERROR] cannot detach from resource that client is not attached to
[ERROR] 'Blubber' has no 'calendar+todo' source
[...]
Can you describe step-by-step what you see in the UI and what you try to
do?
[INFO] calendar: adding "x.x.x. Pr�fung"
==5424== Invalid read of size 1
==5424== at 0x42E5FD7: g_variant_is_trusted (gvariant-core.c:600)
==5424== by 0x42E5179: g_variant_valist_new (gvariant.c:4093)
==5424== by 0x42E53E7: g_variant_new_va (gvariant.c:4248)
==5424== by 0x42E5494: g_variant_new (gvariant.c:4188)
==5424== by 0x5FEA58E: e_gdbus_cal_call_create_object_sync
(e-gdbus-egdbuscal.c:3342)
This looks very much like:
https://bugzilla.gnome.org/show_bug.cgi?id=628299
Note that the word Prüfung seems to have an invalid UTF-8 encoding.
Can you run the sync with a higher log level and then send the -log.html
file to me? Run:
$ syncevolution --daemon=no loglevel=4 blubber calendar
I want to see exactly what data cases it, perhaps I can reproduce it.
--
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.