Created attachment 294207 [details]
(gdb) t a a bt f

Using Debian Sid/unstable with the Evolution-Data-Server package 3.12.9~git20141128.5242b0-2 and SQLite 3.8.7.4, Evolution crashed with a segmentation fault.

    0xb3f9af51 in sqlite3Strlen30 (z=0x18 <error: Cannot access memory at address 0x18>) at sqlite3.c:22902

Here is the backtrace.

+ Trace 234538

Please find the full backtrace attached.

The SQLite developer D. Richard Hipp also analyzed this issue on the mailing lists sqlite-users [1].

>         #6  0xb7ad33d6 in call_old_file_Sync (flags=<optimized out>,
> > cFile=<optimized out>) at camel-db.c:66
>
> The pFile object with the invalid zPath field is a parameter to
> unixSync(), and hence comes from call_old_file_Sync(), which is not a
> part of the SQLite source tree.  I don't have the sources to
> camel-db.c so I cannot trace this any further.  My guess (based on the
> name of the function) is that camel-db.c is trying to "sync" an
> sqlite3_file object that has been previously destroyed.
>
> This appears to be completely unrelated to the previous issue.  The
> previous issue was that a file was not being extended correctly
> because of a lack of disk space, so that a memcpy() into a mmap() of
> that file segfaulted.  That does not appear to be what is happening
> here, unless I'm missing something.

Here is the corresponding function.

static gint
call_old_file_Sync (CamelSqlite3File *cFile,
                    gint flags)
{
	g_return_val_if_fail (old_vfs != NULL, SQLITE_ERROR);
	g_return_val_if_fail (cFile != NULL, SQLITE_ERROR);

	g_return_val_if_fail (cFile->old_vfs_file->pMethods != NULL, SQLITE_ERROR);
→	return cFile->old_vfs_file->pMethods->xSync (cFile->old_vfs_file, flags);
}

[1] https://www.mail-archive.com/sqlite-users@sqlite.org/msg88083.html
[2] http://sources.debian.net/src/evolution-data-server/3.12.9~git20141128.5242b0-2/camel/camel-db.c/#L66