fts uses what is effectively a form of compression for the index, so
most any stream of data will decode at some level. My bet in this
case is that the segdir is referencing a segment block which doesn't
exist, so someone inappropriately tries to decode NULL.
From what I recall of debugging such things in Gears, that case does
tend to go along with being able to detect via PRAGMA integrity_check,
because it happens when a page containing SQLite metadata has been
corrupted. For instance, if an interior node of a b-tree is replaced
by a random other page (perhaps a node was split and the target page
did not get overwritten due to lying disk cache).
What's puzzling is how I know this, but we still see the crash. I'm
pretty sure we fixed something or other around this. That was a year
or more back, though, so maybe I'm not remembering right. Regardless,
best-case scenario for something like this would be someone throwing
SQLITE_CORRUPT and higher-level code doing something like poisoning
(*) or deletion or mount some sort of salvage operation.
-scott
(*) This is what Gears did, it marked the database unusable in a way
that would be recognized by all outstanding handles, and bumped the
version in the mapping so that on next open a fresh new database would
be created. Probably not appropriate in this case.
On Wed, Sep 9, 2009 at 6:34 PM, cpuc...@chromium.org wrote:
Larson gave me a profile that can consistently crash windows chrome
(beta). I haven't tried loading the profile myself but we have crash
dumps from it.
It crashes in:
0x69db6e5d [chrome.dll - fts2.c:453] getVarint --- access
violation at 0x0
0x69db6ef0 [chrome.dll - fts2.c:468] getVarint32
0x69dbacbf [chrome.dll - fts2.c:5078] leavesReaderDataBytes
0x69dbb1d7 [chrome.dll - fts2.c:5407] segmentMerge
0x69dbb0f9 [chrome.dll - fts2.c:5359] segdirNextIndex
0x69dbba45 [chrome.dll - fts2.c:5932] writeZeroSegment
0x69dbbbf5 [chrome.dll - fts2.c:5966] flushPendingTerms
0x69dbbc3c [chrome.dll - fts2.c:5984] initPendingTerms
0x69dba135 [chrome.dll - fts2.c:4050] index_delete
0x69dbbca4 [chrome.dll - fts2.c:6005] fulltextUpdate
0x69dc284a [chrome.dll - vdbe.c:4945] sqlite3VdbeExec
0x69da170f [chrome.dll - vdbeapi.c:476] sqlite3Step
0x69da1856 [chrome.dll - vdbeapi.c:544] sqlite3_step
0x6a09c1ab [chrome.dll - text_database.cc:290]
history::TextDatabase::DeletePageData(..)
0x6a07d145 [chrome.dll - text_database_manager.cc:338]
history::TextDatabaseManager::DeletePageData(...)
0x6a081c4a [chrome.dll - expire_history_backend.cc:366]
history::ExpireHistoryBackend::DeleteVisitRelatedInfo(..);
0x6a082496 [chrome.dll - expire_history_backend.cc:592]
history::ExpireHistoryBackend::ArchiveSomeOldHistory(..)
0x6a0822fa [chrome.dll - expire_history_backend.cc:553]
history::ExpireHistoryBackend::DoArchiveIteration()
0x69ee8de1 [chrome.dll - message_loop.cc:313] MessageLoop::RunTask
(Task *)
The novel part is that sqlite can detect corruption:
D:\testsqlite3.exe zzz\User Data\Default\History Index 2009-09
SQLite version 3.6.17
sqlite PRAGMA integrity_check;
wrong # of entries in index info_time
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
