Wasn't interacting with the browser while it happened. Stack trace: mozcrt19.dll!memcpy(unsigned char * dst=0x0424150f, unsigned char * src=0x068a659b, unsigned long count=0xffff7af9) Line 289 sqlite3.dll!defragmentPage(MemPage * pPage=0x0689d038) Line 27054 + 0x1d bytes sqlite3.dll!allocateSpace(MemPage * pPage=0x0689d099, int nByte=0x00000000) Line 27134 + 0x6 bytes sqlite3.dll!insertCell(MemPage * pPage=0x00000000, int i=0x00000000, unsigned char * pCell=0x040be008, int sz=0x00000009, unsigned char * pTemp=0x00000000, unsigned char nSkip=0x00) Line 30907 sqlite3.dll!sqlite3BtreeInsert(BtCursor * pCur=0x040be008, const void * pKey=0x042a626c, __int64 nKey=0x0000000000000008, const void * pData=0x7354d014, int nData=0x00000000, int nZero=0x00000000, int appendBias=0x00000000) Line 32003 + 0x16 bytes sqlite3.dll!sqlite3VdbeExec(Vdbe * p=0x00000000) Line 41699 + 0x21 bytes sqlite3.dll!sqlite3MemCompare(const Mem * pMem1=0x00000000, const Mem * pMem2=0x00000000, const CollSeq * pColl=0x00000000) Line 34101 + 0x19 bytes sqlite3.dll!pagerSharedLock(Pager * pPager=0x0730001c) Line 23714 + 0xf bytes mozcrt19.dll!extent_tree_ad_s_RB_INSERT(extent_tree_ad_s * head=0x0730001c, extent_node_s * elm=0x00000000) Line 1988 + 0x7a bytes mozcrt19.dll!arena_run_split(arena_s * arena=0x042a68c0, arena_run_s * run=0x00000000, unsigned int size=0x042a68e4, int small=0x00000004, int zero=0x7350383d) Line 2989 + 0xe bytes mozcrt19.dll!arena_run_split(arena_s * arena=0x043a45c8, arena_run_s * run=0x00000000, unsigned int size=0x045ef798, int small=0x80000000, int zero=0x043a45c8) Line 2989 + 0xe bytes sqlite3.dll!sqlite3Step(Vdbe * p=0x00000000) Line 37014 + 0x7 bytes xul.dll!mozStorageStatement::ExecuteStep(int * _retval=0x045ef7c0) Line 472 + 0x9 bytes xul.dll!mozStorageStatement::Execute() Line 449 xul.dll!nsUrlClassifierStore::WriteEntry(nsUrlClassifierEntry & entry={...}) Line 1885 xul.dll!nsUrlClassifierDBServiceWorker::SubChunk(unsigned int tableId=0x00000003, unsigned int chunkNum=0x000013c3, nsTArray<nsUrlClassifierEntry> & entries={...}) Line 2526 xul.dll!nsUrlClassifierDBServiceWorker::ProcessChunk(int * done=0x00000000) + 0x19bf9e bytes xul.dll!nsUrlClassifierDBServiceWorker::UpdateStream(const nsACString_internal & chunk={...}) Line 2942 xul.dll!NS_InvokeByIndex_P(nsISupports * that=0x6886d24d, unsigned int methodIndex=0x0417bc00, unsigned int paramCount=0x00000008, nsXPTCVariant * params=0x00000001) Line 102 nspr4.dll!PR_Unlock(PRLock * lock=0x02ce8610) Line 356 xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x045efab4) Line 510 + 0x5 bytes xul.dll!nsThread::ThreadFunc(void * arg=0x041a9a60) Line 254 + 0xc bytes nspr4.dll!_PR_NativeRunThread(void * arg=0x04124400) Line 458 nspr4.dll!pr_root(void * arg=0x04124400) Line 122 + 0xd bytes mozcrt19.dll!_callthreadstartex() Line 348 + 0x9 bytes mozcrt19.dll!_threadstartex(void * ptd=0x0417bc00) Line 326 + 0x5 bytes kernel32.dll!77124911() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!76f9e4b6() ntdll.dll!76f9e489()

Maybe the blob stuff in BindStatement isn't giving the right lengths (unlikely) or we don't actually have data there? http://mxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp#666 If you get this crash again, I'd like to see more details of the entry object from here: xul.dll!nsUrlClassifierStore::WriteEntry(nsUrlClassifierEntry & entry={...}) Line 1885

Firefox crashes once per hour. Using a build from m-c today I was able to get all the debugging info. Here's the entry: mId: -1 mKey: { bd 76 dc 73 } mHavePartial: 1 mPartialHash: { 7e 48 d3 4f } mHaveComplete: 0 mCompleteHash: { cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd 03 00 00 00 } mTableId: 3 mChunkId: 5059 mAddChunkId: 5016 The 0xcd bits in mCompleteHash indicate that the memory wasn't initialized. I don't know enough about this code to know if that's ok or not.

That looks to be OK because it's a partial hash anyway.

I put a gzip'ed copy of rob's urlclassifierdb at http://campd.org/stuff/urlclassifier3.sqlite.gz . An integrity_check shows some corruption that may be confusing sqlite? (we run with SYNCHRONOUS=OFF to get reasonable performance, and throw away the db if we run across corruption) I ran with this db on my machine - the first update detects corruption (returns SQLITE_CORRUPT), which when 434805 lands would cause the db to be wiped and rebuilt. The second update doesn't detect corruption, it just crashes. If it helps - after the first update fails we roll back the transaction. The next update starts a new one.

The database file is corrupt. But SQLite should not segfault even on a corrupt database. If you can tell me the SQL that was running at the point of the segfault, that will help me to track down the problem and fix it.

It's running mInsertStatement, which is INSERT OR REPLACE INTO moz_subs VALUES(?, ?, ?, ?, ?, ?). The particular values it's using (from what rob pasted above) are: INSERT OR REPLACE INTO moz_subs VALUES(null, X'bd76dc73', x'7e48d34f', null, 5059, 3, 5016); Running that statement alone isn't crashing my sqlite, are you going to need a log of statements that reproduce the crash?

I found that it segfaults if I run REINDEX on the bad database. I can reproduce the problem now, so a fix will likely be available soon.

this will be fixed in 3.6.0

Fixed by the sqlite upgrade on mozilla-central. I've nominated that for branch as well.

Fixed in 1.9.0.10 with bug 488710

I ran 1.9.0.8 with the sqlite filementioned above (http://campd.org/stuff/urlclassifier3.sqlite.gz) in my profile but it did not crash. Is there a specific way to trigger the crash?