If SQLite is crashing due to corruption in the database, we should be
able to get Dr Hipp to help fix it. But we'd need a repeatable case
to send to him. If we had a database which demonstrated this, I could
certainly see about crafting a simplified database of example data to
replicate the problem.
If it's due to the in-memory data structures being corrupted, that's a
whole 'nother kettle of fish, I'm not sure what SQLite can really do
about that. An idea I've had in the past was so implement a custom
memory allocator to keep the SQLite data structures in a distinct zone
from regular data structures, so that you at least can't get the case
of stale references being used to overwrite data structures, and
should help protect against other code's buffer overflows. Random
rogue pointers would still be dangerous, though!
Some of our databases we preemptively read to warm up the disk cache,
so just running PRAGMA integrity_check; might be cheap enough to be
useful. Another option we could consider would be adding (or looking
for) code to checksum pages. We could also perhaps implement
independent page validity checks at the VFS layer, before things go to
disk, to protect against in-memory structures being corrupted, which
could at least keep things valid at a metadata level.
In my experience SQLite is pretty good about throwing SQLITE_CORRUPT
when it detects corruption, but due to how data is encoded there are a
lot of cases where the corruption is not easy to detect w/in SQLite
(you get back garbage, but it's well-formed garbage :-). If SQLite
itself is overrunning buffers or something, that's a definite bug
which I'm sure Dr Hipp would be interested in helping fix.
-scott
On Fri, Mar 6, 2009 at 10:02 AM, Erik Kay <erik...@chromium.org> wrote:
>
> On Fri, Mar 6, 2009 at 9:33 AM, Brett Wilson <bre...@google.com> wrote:
>> Getting the database has helped in a few cases where it turned out some
>> assumptions were being violated, but if the sqlite data structures are
>> corrupted, getting the DB has never been helpful to diagnose the root cause.
>>
>> It might help us make sqlite not crash for these types of corruption,
>> though.
>>
>> I think we should install an exception handler on the DB threads, and if we
>> get two crashes in a row from sqlite, recreate the DB.
>
> Yep. This would be nice. If these crashes are really this frequent,
> perhaps we should move the db out of the browser process. Or perhaps
> we could simply have an out of process validator that we could run if
> we got a single browser crash from sqlite.
>
> Erik
>
>
>
>> Brett
>>
>> On Mar 6, 2009 9:19 AM, "Erik Kay" <erik...@chromium.org> wrote:
>>
>>
>> One thing that would help is if some of the users who are running into
>> this would be willing to share their whole profile with us.
>>
>> While our best guess is that this is sqlite corruption, we don't know
>> for sure. Even if it is sqlite corruption, having the specific db
>> might help us figure out how to more reliably detect it.
>>
>> Erik
>>
>> On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson <fin...@chromium.org>
>> wrote: > I suspect this...
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
