On Thu, 2012-03-01 at 15:25 +0200, Juha Pahkala wrote:
> On 02/29/2012 03:22 PM, Patrick Ohly wrote:
> > On Mon, 2012-02-27 at 14:32 +0200, Juha Pahkala wrote:
> >>
> >> Sure. Just did and sent the output to you.
> > The concatenation in the XML message dump is indeed an artifact of how
> > buffers are handled; it's not the root cause of the problem.
> >
> > I tried to reproduce the decoding problem by feeding the same message
> > into a local SyncEvolution installation, but after making a few changes
> > to the message to fit into a normal session the problem didn't occur.
> >
> > Juha, I have to rely on you for some remote debugging.
>
> Sure thing, no problem, other than the fact that I'll be away for two
> weeks from Saturday onwards, but before and after, I'm glad to help.
>
> > As a first step, please use the pre-release 1.2.99+20120228+SE+cb0b7f6
> > +SYSYNC+5e0f652 from the experimental apt repo on syncevolution.org or
> > from dowloads.syncevolution.org.
> I tried the .deb package, but it depended on kde,
How much of a problem is that?
I had to make a choice between compiling and packaging SyncEvolution
once, which implies that these binaries are run through all tests, and
compiling multiple times (for Evolution, for KDE) and then only
partially testing each package.
In the end I went for compiling once, because it is also less work.
What I could do is disable the KDE UI dependencies in the core
SyncEvolution by disabling KWallet support. The dependency on Akonadi in
the Akonadi backend doesn't have to be a hard dependency because only an
optional module depends on it. Failing to load that when libs are
missing is handled.
Yet another option, already discussed before, is to move
platform-specific code into modules. But that'll require further changes
to source code.
> so I skipped it and
> tried the binary build instead. That gave me some dbus version error,
> can't recall what it was.
You mean the .tar.gz? For that you still need the same KDE libs
(libkdeui, libkdecore, QtDbus, ...) on the system, otherwise
SyncEvolution can't start.
> Anyhow, compiling the source worked out, and I
> ran it again. Output sent to you.
Thanks. It remains a mystery. The logs show that it seems to parse six
vCards (last one: N:Tho). I don't see anything special in that vCard or
the one after it.
I also don't see any particular limits in the code, items in the Replace
command are a linked list that can be extended infinitely.
> > It has additional debug printing enabled in the SyncML Toolkit. Please
> > send me another server-side log of a failed sync attempt with that
> > version.
> >
> > Perhaps it'll tell me something (not sure yet).
> >
> > If it doesn't, do you know gdb well enough to step through the source
> > code manually?
> >
> Hmm, don't know gdb at all, but I do have some experience of debugging
> and stepping through source code... so I'm pretty sure I'll be able to help.
Please give it a try. Run "script /tmp/gdb.log; gdb
syncevo-dbus-server". Set a breakpoint in buildGenericCmd:
$ gdb /usr/libexec/syncevo-dbus-server
...
Reading symbols from /usr/libexec/syncevo-dbus-server...done.
(gdb) b buildGenericCmd
Function "buildGenericCmd" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (buildGenericCmd) pending.
(gdb) run
The symbol should get resolved once the shared libs are loaded.
Then run syncevo-http-server in a separate window. I think the first
call of buildGenericCmd() will be the right one, for the Replace command
in the second incoming message.
What we are looking out for is the place where the return code (usually
called rc) is set to SML_ERR_XLT_INVAL_SYNCML_DOC == 0x200B.
I suspect that the culprit is either inside appendItemList() or the
default case:
case TN_ITEM:
rc = appendItemList(pDecoder, &pGenCmd->itemList);
items++;
break;
default:
rc =
SML_DECODEERROR(SML_ERR_XLT_INVAL_SYNCML_DOC,pScanner,"buildGenericCmd");
So it should be okay to step over all other functions (with n = next)
and only step into appendItemList() with s (= step).
But before you do that, let's try a simpler approach for locating the
parse error:
$ gdb /usr/libexec/syncevo-dbus-server
...
(gdb) run
Starting program: /usr/libexec/syncevo-dbus-server
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
File "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py", line 59, in
<module>
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
^CStopped due to shared library event
Quit
(gdb) b show_decode_error
Breakpoint 1 at 0x7ffff0058e00: file
/data/runtests/work/sources/libsynthesis/src/syncml_tk/src/sml/xlt/all/xltdec.c,
line 235.
(gdb) cond 1 aRc == 0x200b
(gdb) c
Continuing.
...
I expect that to stop at the breakpoint. What's the output of "bt" then?
If never stops there, then perhaps SML_ERR_XLT_INVAL_SYNCML_DOC is set
in those few places which are not wrapped in SML_DECODEERROR(). A grep
of the source turned up some places:
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:77: return
SML_ERR_XLT_INVAL_SYNCML_DOC;
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:104: rc =
SML_ERR_XLT_INVAL_SYNCML_DOC;
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:130: return
SML_ERR_XLT_INVAL_SYNCML_DOC;
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:169: rc =
SML_ERR_XLT_INVAL_SYNCML_DOC;
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:196: return
SML_ERR_XLT_INVAL_SYNCML_DOC;
src/syncml_tk/src/sml/xlt/all/xltmetinf.c:260:
In gdb, after "b show_decode_error", can you also cut-and-paste this:
b xltmetinf.c:77
b xltmetinf.c:104
b xltmetinf.c:130
b xltmetinf.c:169
b xltmetinf.c:196
b xltmetinf.c:260
If it never stops at any of these breakpoints, then please send me the
syncevolution-log.html of that failed sync. There must be an error in it
which is different from the one seen before.
If it stops and you used the "script" command, then /tmp/gdb.log will
have a full dump of your debug session. That's what you can send me.
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
