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
Index: src/os_unix.c
==================================================================
--- src/os_unix.c
+++ src/os_unix.c
@@ -3716,20 +3716,20 @@
** on systems that do not have a real fallocate() system call.
*/
int nBlk = buf.st_blksize; /* File-system block size */
i64 iWrite; /* Next offset to write to */
- if( robust_ftruncate(pFile->h, nSize) ){
- pFile->lastErrno = errno;
- return unixLogError(SQLITE_IOERR_TRUNCATE, "ftruncate", pFile->zPath);
- }
iWrite = ((buf.st_size + 2*nBlk - 1)/nBlk)*nBlk-1;
while( iWrite<nSize ){
int nWrite = seekAndWrite(pFile, iWrite, "", 1);
if( nWrite!=1 ) return SQLITE_IOERR_WRITE;
iWrite += nBlk;
}
+ if( robust_ftruncate(pFile->h, nSize) ){
+ pFile->lastErrno = errno;
+ return unixLogError(SQLITE_IOERR_TRUNCATE, "ftruncate", pFile->zPath);
+ }
#endif
}
}
#if SQLITE_MAX_MMAP_SIZE>0
Index: src/vdbesort.c
==================================================================
--- src/vdbesort.c
+++ src/vdbesort.c
@@ -1130,16 +1130,16 @@
** Whether or not the file does end up memory mapped of course depends on
** the specific VFS implementation.
*/
static void vdbeSorterExtendFile(sqlite3 *db, sqlite3_file *pFd, i64 nByte){
if( nByte<=(i64)(db->nMaxSorterMmap) && pFd->pMethods->iVersion>=3 ){
- int rc = sqlite3OsTruncate(pFd, nByte);
- if( rc==SQLITE_OK ){
- void *p = 0;
- sqlite3OsFetch(pFd, 0, (int)nByte, &p);
- sqlite3OsUnfetch(pFd, 0, p);
- }
+ void *p = 0;
+ int chunksize = 4*1024;
+ sqlite3OsFileControlHint(pFd, SQLITE_FCNTL_CHUNK_SIZE, &chunksize);
+ sqlite3OsFileControlHint(pFd, SQLITE_FCNTL_SIZE_HINT, &nByte);
+ sqlite3OsFetch(pFd, 0, (int)nByte, &p);
+ sqlite3OsUnfetch(pFd, 0, p);
}
}
#else
# define vdbeSorterExtendFile(x,y,z)
#endif
signature.asc
Description: This is a digitally signed message part
_______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
