Am Freitag, den 09.01.2015, 21:04 -0500 schrieb Richard Hipp: > On 1/9/15, Paul Menzel wrote: > > Am Dienstag, den 30.12.2014, 16:15 +0100 schrieb Paul Menzel: > > > > With still around 1.3 GB free on the partition mounted to `/var/`, > > Evolution crashed with the f received the following segmentation fault > > today. > > Which build of SQLite are you using. What is SQLITE_SOURCE_ID?
I downloaded the source of Debian package for SQLite 3.8.7.4-1 and
applied the patch from [2] (also attached).
$ /usr/bin/sqlite3 --version
3.8.7.4 2014-12-09 01:34:36
f66f7a17b78ba617acde90fc810107f34f1a1f2e
> Also, we have some new "sqlite3.c" and "sqlite3.h" files for the
> upcoming 3.8.8 release. Can I encourage you to try them out.
I’ll try to test the 3.8.8 files. Unfortunately, I have not found a way
to reproduce the issue.
> > 0xb3f9af51 in sqlite3Strlen30 (z=0x18 <error: Cannot access memory
> > at address 0x18>) at sqlite3.c:22902
> >
> >
> > Thread 53 (Thread 0xa7e04b40 (LWP 3576)):
> > #0 0xb3f9af51 in sqlite3Strlen30 (z=0x18 <error: Cannot access
> > memory at address 0x18>) at sqlite3.c:22902
>
> sqlite3Strlen30() is called with an invalid string pointer,
> apparently. The sqlite3Strlen30() function is just a strlen()
> implementation that returns int instead of size_t. Stack frames 0
> through 5 look fine, except for the invalid string pointer, of coruse.
>
> > #5 0xb3f9ce21 in unixSync (id=0xacbe7898, flags=2) at
> > sqlite3.c:28396
> > dirfd = 668585276
> > rc = <optimized out>
> > pFile = 0xacbe7898
> > isDataOnly = 0
> > isFullsync = 0
>
> The unixSync routine above calls frame 4 from
> (https://www.sqlite.org/src/artifact/949cdedc74dbf3c1?ln=3589).
> Apparently, pFile->zPath is an invalid pointer.
>
>
> > #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.
You can view the source at [3].
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);
}
> 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.
That sounds reasonable. I created a ticket in GNOME’s bug tracker
Bugzilla and it was assigned the ID #742688 [4]. I added you to the CC
list. Hopefully, you do not mind.
> 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.
[…]
As always thank you very much for the quick and detailed reply!
Thanks,
Paul
> >> [1] https://packages.debian.org/corekeeper
> >> [2]
> >> https://www.sqlite.org/src/info/776648412c30dce206f1024ff849c2cb025bb006
[3]
http://sources.debian.net/src/evolution-data-server/3.12.9~git20141128.5242b0-2/camel/camel-db.c/#L66
[4] https://bugzilla.gnome.org/show_bug.cgi?id=742688
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
