View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003169SOGoActiveSyncpublic2015-04-12 08:272015-09-09 17:48
Reportermzubcic Assigned Toludovic  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionsuspended 
Platform[Server] LinuxOSRHEL/CentOSOS Version6
Summary0003169: sogod child dies with NSCharacterConversionException
Description

Hello,

While doing initial sync of one large IMAP account (Cyrus IMAP 2.4.17), after half an hour, sogo worker child terminates with:

EXCEPTION: <NSException: 0x7f53b13b5e68> NAME:NSCharacterConversionException REASON:Can't get cString from Unicode string. INFO:(null)
Apr 12 09:37:18 sogod [2949]: <0x0x7f537a5f63b8[WOWatchDogChild]> child 3029 exited
Apr 12 09:37:18 sogod [2949]: <0x0x7f537a5f63b8[WOWatchDogChild]> (terminated due to signal 6)

... and that's it. It tries again and again, but account is never synced because of this stopper.

I have attached strace (for open(2) syscall) on IMAP server to catch erroneous message and find it. It is a multibyte multipart/mixed UTF-8 plain text + html message with simple base64 encoded txt attachment.

Command line base64 -d < message.txt reports "bbase64: invalid input".

While this message is obviously invalid, there can be such messages in the future, and it causes sogo sync to become disfunctional.

Steps To Reproduce

2 ways:

a) You can make damage by hand in some message in cyrus imapd store, check with base64 command that it reports "invalid input", and try to sync it to Outlook or whatever.

b) My own message is (as always in Murphy's law!) sensitive and has really some content which cannot be posted public (including invalid base64 attachment). I can send it directly to developer by request (for example, if step a) is not reporoducable).

TagsNo tags attached.

Activities

ludovic

ludovic

2015-04-13 00:31

administrator   ~0008415

Send a sample to me - lmarcotte@inverse.ca
ludovic

ludovic

2015-09-09 17:48

administrator   ~0008905

Suspending for now - please make sure you test with the latest nightly build before reopening.

Issue History

Date Modified Username Field Change
2015-04-12 08:27 mzubcic New Issue
2015-04-13 00:31 ludovic Note Added: 0008415
2015-09-09 17:48 ludovic Note Added: 0008905
2015-09-09 17:48 ludovic Status new => resolved
2015-09-09 17:48 ludovic Resolution open => suspended
2015-09-09 17:48 ludovic Assigned To => ludovic