this crash was reported by a user at the german Fx forum. bp-eba607e6-a6bd-11dd-94ba-001a4bd43ef6 Signature fastzero_I UUID eba607e6-a6bd-11dd-94ba-001a4bd43ef6 Time 2008-10-30 13:09:46-07 Uptime 10 Product Firefox Version 3.0.3 Build ID 2008092417 OS Windows NT OS Version 5.1.2600 Service Pack 2 CPU x86 CPU Info AuthenticAMD family 15 model 67 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x67ff000 Frame Module Signature Source 0 mozcrt19.dll fastzero_I 1 mozcrt19.dll _VEC_memzero 2 mozcrt19.dll _VEC_memcpy 3 sqlite3.dll defragmentPage mozilla/db/sqlite3/src/sqlite3.c:30672 4 sqlite3.dll insertCell mozilla/db/sqlite3/src/sqlite3.c:34549 5 sqlite3.dll sqlite3BtreeInsert mozilla/db/sqlite3/src/sqlite3.c:35665 6 sqlite3.dll sqlite3VdbeExec mozilla/db/sqlite3/src/sqlite3.c:45747 7 sqlite3.dll sqlite3Step mozilla/db/sqlite3/src/sqlite3.c:41212 8 sqlite3.dll sqlite3_step mozilla/db/sqlite3/src/sqlite3.c:41276 9 xul.dll mozStorageStatement::ExecuteStep(int*) mozilla/storage/src/mozStorageStatement.cpp:472 10 xul.dll mozStorageStatement::Execute() mozilla/storage/src/mozStorageStatement.cpp:448 11 xul.dll nsUrlClassifierStore::WriteEntry(nsUrlClassifierEntry&) mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:1887 12 xul.dll nsUrlClassifierDBServiceWorker::AddChunk(unsigned int,unsigned int,nsTArray<nsUrlClassifierEntry>&) mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2438 13 xul.dll nsUrlClassifierDBServiceWorker::ProcessChunk(int*) mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2572 14 xul.dll nsUrlClassifierDBServiceWorker::UpdateStream(nsACString_internal const&) mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2944 15 xul.dll NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 16 nspr4.dll PR_Unlock mozilla/nsprpub/pr/src/threads/combined/prulock.c:355 17 xul.dll nsThread::ProcessNextEvent(int,int*) mozilla/xpcom/threads/nsThread.cpp:510 18 xul.dll nsThread::ThreadFunc(void*) mozilla/xpcom/threads/nsThread.cpp:254 19 @0x2afff6b the crash was said to happen just by using Fx for 5 minutes and happens in safe-mode too. further examples i researched (more or less same stack): bp-9030d40f-a3e1-11dd-b751-001a4bd43ef6 (Firefox 3.0.4pre 2008102405) bp-b9b5bd99-a64e-11dd-addd-001a4bd43ef6 (Firefox 3.1b1 20081007144708) bp-5a94ddd1-a4d2-11dd-90df-001cc45a2c28 (Firefox 3.1b2pre 20081019033640) according to http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0.3 this is ranked #22 as of 2008-10-16 and it's not listed on https://wiki.mozilla.org/QA/Topcrashes.

Shawn, do you have by chance any idea on this thingy (specific sqlite issue?)?

these are only useful if we can get a copy of the db that crashes. Without it, these bugs are INCOMPLETE

INCOMPLETE per comment 2

Looks like it's #33 topcrash in 3.0.7 per http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0.7 We're seeing this quite a bit on support too ... is it most likely cookies.sqlite, bookmarks.sqlite or other? We can see if we can get permission from users to get those files and stick them in a security bug or something. Anything else we should be asking users with this problem?

i pulled a report, 7876 instances, all reported on windows in the last 2 weeks. http://bit.ly/fastzero_I. Seems like all are on windows only. We'll need testcases to get more info. Shawn, can you specify here which db you need from people to diagnose? reopening for now.

based on the crash reports I looked at, it's the url classifier. Of course, there's really no point in getting more data if this is fixed in a newer SQLite. Is this crash showing up in the recent 1.9.1 beta 3 release?

As of right now, there is no b3 instances of this crash recorded. However, I'll revisit this in a week and see if its there or not. Meanwhile, it's still a problem on 3.0.7. Would there be no solution for this against the 1.9.0 branch?

can't bug 471685 be backported to 1.9.0?

(In reply to comment #8) > can't bug 471685 be backported to 1.9.0? AIUI, sqlite updates are tested against betas first. the 1.9.0 drivers remind me that they've tried this once on fx3.0.4, but had to back it out due to instability. SO answer is likely no, but sdwilsh can comment further if i'm wrong.

We don't take patches to SQLite, just new versions. There's a number of reasons for this really (that I'd rather not have to iterate)

Fixed in 1.9.0.10 with bug 488710

bug 488710 updates sqlite but I'd rather wait to see if the topcrash goes away before marking this as verified for 1.9.0.11.