3510			_("Error appending message"));
3511		success = FALSE;
3512
3513	} else if (ic->status->condition == IMAPX_APPENDUID) {
3514		c(is->tagprefix, "Got appenduid %d %d\n", (gint)ic->status->..
3515		if (ic->status->u.appenduid.uidvalidity == ...
3516			CamelFolderChangeInfo *changes;

I am able to reproduce this, when running two copy operations simultaneously. I run one copy of a message to imapx folder which is large enough that it takes some till it's uploaded to the server, and while it's in progress I take another message and copy it to another folder in the imapx server. When it finishes this crashes. valgrind doesn't give anything useful:

 Thread 8:
 Invalid read of size 4
    at 0x2E363253: imapx_command_append_message_done (camel-imapx-server.c:3551)
    by 0x2E3676AA: cancel_all_jobs (camel-imapx-server.c:5298)
    by 0x2E3679B9: imapx_parser_thread (camel-imapx-server.c:5388)
    by 0x3DDE86A314: g_thread_proxy (gthread.c:801)
    by 0x3DDD007D13: start_thread (in /usr/lib64/libpthread-2.15.so)
    by 0x3DDCCF199C: clone (in /usr/lib64/libc-2.15.so)
  Address 0x4 is not stack'd, malloc'd or (recently) free'd

My line numbers are from git's gnome-3-4 branch at commit 777c487.

Nice, the parser thread receives an error "Error appending message: Command is not valid in this state.\r\n" and it panics on it and closes itself.

I can easily workaround the crash, by adding check for NULL ic->status, but it'll make the parser thread stop anyway. The real fix, it seems, might be to wait until the first APPEND is finished, and only then start the next APPEND, because some servers don't like interleaving of command (hence the error message). When I tried with the same thing on a dovecot server then it worked as expected, no error from the server, no crash.

With dovecot server I see after the first message write is done:
[imapx:B] 0x2652720: queueing continuation
[imapx:B] camel_imapx_write: '
'
[imapx:B] adding command, format = 'APPEND %f %F %P'
[imapx:B] got folder 'INBOX/B'
[imapx:?] looking up path INBOX/B -> INBOX.B
[imapx:B] got file path '/home/.../new/00/tempuid-4fd75d7d-1'
[imapx:B] completing command buffer is [0] ''
[imapx:B] enqueue job 'APPEND "INBOX.B" (\SEEN) {43098+}'
[imapx:B] ** Starting next command
[imapx:B] * queueing job -60 'APPEND'
[imapx:B] completing command buffer is [0] ''
[imapx:B] Starting command (active=2, literal) B00013 APPEND "INBOX.B" (\SEEN) {43098+}
[imapx:B] camel_imapx_write: 'B00013 APPEND "INBOX.B" (\SEEN) {43098+}
'
[imapx:B] camel_imapx_read: buffer is 'B00012 OK [APPENDUID 1339446789 4] Append completed.
'
[imapx:B] token TOKEN 'B00012'
[imapx:B] sending LITERAL+ continuation
...

Where my other server, after the first "queueing continuation" and the other camel_imapx_write for the APPEND command that the read isn't finished with APPENDUID, but with the error.

As far as I understand the issue, I think the IMAPX wrote data to the stream before previous APPEND command had been finished and confirmed s such by the server. Some servers are fine with this, some are not.

I committed a workaround for this bug, just for the crash, thus the error returned form the server is propagated to UI, though I would like to see the right fox for this - do not start other command until the previous one is finished and confirmed as finished by the server, but as I'm rather lost in imapx, then I cannot do it myself, sadly.

Created commit f08d0a3 in eds master (3.5.3+)
Created commit fb2c8a0 in eds gnome-3-4 (3.4.3+)

This will be addressed by bug #745545, let's mark this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 745545 ***