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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
