Re: [SyncEvolution] Syncevo & funambol (Android)
On Do, 2011-09-15 at 14:14 +0200, Andre Colomb wrote:
What I found was that the incoming message 003_006 (mine was
numbered
the same) contained a full copy of the previous message. That was
surprisingly close to the 64k maxMsgSize I had set IIRC. After that
followed another <SyncML> tag starting the next message. However, the
XML was declared (even by the browser) as not well-formed (or not
valid?) because of the repeated top-level tag. Looked to me a bit like
the message buffer had not been cleared after reaching the maximum
message size.
I see the same issue, but I discarded it as an artifact of how the
buffer handling internally works: the response message is appended at
the end of incoming messages. It could be that dumping the buffer in an
error case dumps everything because it doesn't know the right length.
Supporting that interpretation is the fact that the Synthesis engine
never sees the <Replace> command. The XML seems well-formed to me until
the end of that and I would expect the libsmltk to report that before
moving on.
It would be useful to verify that it isn't the client sending the
message like that by looking at a Wireshark trace.
Dunno whether it's a client or server issue. I was using
SyncEvolution
1.1.99.5a from Debian unstable and the Android Funambol client 10.0.6. I
could not find that specific log directory just now, but I'll try to
reproduce it next week or so and send you the log directory for
additional reference.
I don't think it would help much. You could do the Wireshark thing, or,
if you are really ambitious, single-step through buildGenericCmd() in
xltdec.c while it processes the offending <Sync><Replace> part. That
should eventually bomb out somewhere with the
SML_ERR_XLT_INVAL_SYNCML_DOC error.
--
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.