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, cpu<[email protected]> 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:\test>sqlite3.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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
