Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
The kolab xml mail part input of the converter lib sometimes contains undefined content at the end of the document.
e.g. at line 294 and 407 in the attached log. This content can be differnet for the same kolab email at different times.
example email which is shown in the log file
There is also a segfault at the end of the attached log
did you ever notice anything alike with attachments other than the Kolab XML, e.g. has any other attachment ever been mangled in a similar way? If so, then attachment data should have experienced corruption when tested. The code for handling mime parts is the same for Kolab XML and other, arbitrary attachments - that is, I'm relying on the size information I get from Camel when it comes to the size of mime part content objects and how many bytes to stuff into a Kolab_conv_mail_part.
i did not notice that behavior for other attachments, but that does not mean much. I can not add attachments in Kontact Version 1.2.9 (enterprise35 20100115.1075236) because of a bug in this version. But i can add a photo to a contact which ends in a mail attachment and i did not see any problems there. But if the corrupt content is only extending the attachment at its end it could go unnoticed because anything after the image end marker could be uninterpretated .
in my tests so far, attachments other than the Kolab XML part were left untouched by Evo (attached with Kontact 4.4.8 and pushed to server, pulled with Evo and changed some detail, written back to server, pulled with Kontact and done a bitwise compare (cmp) of the attachment received with the original one).
When the bug shows, did you have a chance to check the actual contents of the Kolab XML part directly on the server? All attachments (all, but the Kolab XML) get 8BIT set as transport encoding, whereas the Kolab XML is sent through Camel with 7BIT transport encoding. I might need to change this so the Kolab XML gets transported as 8BIT as well (and eventually be converted to base64, if needed, before going over the wire)
i checked an event which has such a suffix when it is the input of the converter lib on the kolab server.
The Kolab XML part of the mail looks ok and does not have this suffix
it seems like the length of the xml memory block gets to big somewhere between reading the kolab mail and passing it to the converter lib.
has this bug shown with recent dev_kc-0.0.6?
i have not been abble to verify the bug so far, and dev_kc-0.0.6 has a fix in mail message handling which may also have fixed this bug. leaving the bug open for now
i think this is still existing. i saw it yesterday in the logs (probably version 0.0.8)