Re: [Tracker] Avoid SQLite versions 3.7.10 - 3.7.13

[Sam Thursfield <ssssam gmail com>]

On Fri, May 31, 2013 at 11:45 AM, Martyn Russell <martyn lanedo com> wrote:
> On 30/05/13 10:31, Sam Thursfield wrote:
> > I noticed that Fedora 18 is now shipping 3.7.13, and yet I'm not
> > experiencing the segfault. Looks like they found the root cause and
> > patched it themselkves:
> > https://bugzilla.redhat.com/show_bug.cgi?id=801981
> >
> > So, my original diagnosis wasn't quite correct, which explains why I
> > couldn't correlate it with the SQLite release notes. In fact there's
> > some bug where SQLite breaks if malloc_usable_size() is used, at least
> > on Fedora. As of today Fedora are still carrying the patch, the bug I
> > linked to above makes no mention of reporting it upstream, and the
> > SQLite release notes show no mention of it being fixed.
> >
> > I don't have time to investigate more now, but since we link to this
> > mail in the configure script I couldn't leave it uncorrected :)
>
>
> Thanks for noticing and notifying everyone here Sam! :)

No problem :)

I had a look through the archives of sqlite-users sqlite org  The
issue has been discussed once, last year. You have to sign up to the
mailing list to read the archives so I'll take the liberty of
reposting the mail here:

On Mon, 23 Jul 2012, Richard Hipp <drh at sqlite.org> wrote:
> On Mon, Jul 23, 2012 at 9:31 AM, Shlomi Fish <shlomif at shlomifish.org> wrote:
> > I first suspected svn was the culprit, so I rebuilt it, but it still
> > happened.
> > Then I tried build SQLite and running its tests and I got this (below). I
> > should note that svn works fine after I type "unset MALLOC_CHECK_" in the
> > console (don't know about the sqlite tests).
> >
> > What is the underlying problem and how can it be fixed?
>
> Thanks for the report.
>
> As best I can tell, this appears to be a bug in MALLOC_CHECK_ in that it
> does not play well with malloc_usable_size().  There does not appear to be
> anything wrong with SQLite in this respect, at least as not as far as I can
> see.
>
> We test SQLite using a variety of memory allocator that do things similar
> to MALLOC_CHECK_.  (See http://www.sqlite.org/testing.html#valgrind for
> example.)  In particular, SQLite tests run clean under valgrind.
>
> If you edit the "config.h" file generated by the ./configure script and
> remove the HAVE_MALLOC_USABLE_SIZE define, then the resulting SQLite will
> not attempt to use malloc_usable_size() and it then appears to work fine
> with MALLOC_CHECK_.  However, if you do this, then SQLite will increase the
> size of every memory allocation by 8 bytes and store the allocation size in
> those 8 bytes so that it can figure out the allocation size for itself when
> it needs it, meaning that the code will run a little slower and use a
> little more memory.
>
> --
> D. Richard Hipp
> drh at sqlite.org

I'm still not really satisfied with this explanation because I've
never had MALLOC_CHECK_ set, and it doesn't get set by the test suite,
and yet I still experienced the segfault. We're a bit further down the
rabbit hole, anyway. Also I never knew that MALLOC_CHECK_ existed at
all before last week :)

Sam