Re: [Evolution] [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4

[Paul Menzel <paulepanter users sourceforge net>]

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

Attachment: mem.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part