Closed Bug 423943 Opened 17 years ago Closed 10 years ago

Repeated crash [@mozStorageStatement::ExecuteStep(int*)]

Categories

(Core :: SQLite and Embedded Database Bindings, defect)

1.9.0 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: faaborg, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [needs a victim to figure out steps or attach a busted phishing database])

Crash Data

Firefox is crashing on me every few minutes, the crash is occurring in mozStorageStatement::ExecuteStep(int*) Here is one of the crash reports: http://crash-stats.mozilla.com/report/index/53fd1eb8-f5ef-11dc-97b8-001a4bd43e5c Any suggestions on how I can potentially correct my profile or otherwise avoid the issue so that I can continue to use Firefox?
switching to DM per the crash report
Component: Places → Download Manager
QA Contact: places → download.manager
(In reply to comment #0) > Any suggestions on how I can potentially correct my profile or otherwise avoid > the issue so that I can continue to use Firefox? > maybe try clearing your downloads, as the crash seems to be occurring there.
Is the frame information right? nsUrlClassifierStore::WriteEntry(nsUrlClassifierEntry&) mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp:1787 We don't have anything using nsUrlClassifier in the download manager. http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp&rev=1.70&mark=1773,1788#1772 There is an Execute statement on line 1787 (1788) in that file.. dcamp?
Blocks: 419117
(In reply to comment #3) > Is the frame information right? The url-classifier stuff is on another thread, so breakpad probably got confused. :(
Component: Download Manager → Phishing Protection
QA Contact: download.manager → phishing.protection
Version: unspecified → Trunk
I don't think it has anything to do with the threads. The stabs symbol dumper currently misses some files, so it's probably just giving you the wrong file name there. Mardak is on the right track here, the line numbers are correct, just substitute nsURLClassifierDBService.cpp in there.
Crashes stopped when I moved ~/Library/Caches/Firefox/<profile>/urlclassifier3.sqlite out of the way. dcamp has a copy of the file and is looking at it.
If you can find this on 1.9.1/1.9.2 we should have a better stack, since we're using DWARF symbols there.
Alex's first report is gone from soccoro now so I'm having a hard time figuring out which mozstoragestatement or sqlite bug we are tracking here. 3.0.10 has a number of stacksignatures with the most popular being 3048 sqlite3VdbeIdxRowidLen 1464 sqlite3BtreeParseCellPtr 644 sqlite3BtreeMoveto 554 sqlite3VdbeExec 387 sqlite3GetVarint 257 libsqlite3.dylib@0xb09d 151 sqlite3_malloc 136 libsqlite3.dylib@0x102b4 92 libsqlite3.dylib@0x1500a 91 libsqlite3.dylib@0x150a8 69 libsqlite3.dylib@0xdf70 57 sqlite3CreateIndex 47 sqlite3VdbeIdxRowid 39 sqlite3WhereBegin 34 sqlite3BtreeInitPage 33 sqlite3Step 29 sqlite3VdbeSerialGet 23 sqlite3Update 31 mozStorageStatementParams::SetProperty(nsIXPConnectWrappedNative*, 5 mozStorageStatement::Reset() 5 mozStorageStatement::ExecuteStep(int*) 5 mozStorageStatement::BindUTF8StringParameter(unsigned 3.5b4 has these most popular sqlite signatures 173 sqlite3VdbeIntValue 57 sqlite3ValueText 23 sqlite3VdbeExec 20 sqlite3_column_bytes 12 sqlite3_column_type 12 sqlite3Insert 11 sqlite3Step 10 sqlite3BtreeMovetoUnpacked 10 sqlite3.dll@0x5fe58 8 free 7 sqlite3BtreeParseCellPtr 6 sqlite3VdbeChangeP5 6 sqlite3MemMalloc 5 sqlite3VdbeSerialPut 5 sqlite3VdbeSerialGet 5 sqlite3MemSize 4 sqlite3ViewGetColumnNames 4 sqlite3VdbeMemGrow 4 sqlite3VXPrintf 4 sqlite3Fts3HashInsert 3 sqlite3VdbeMemReleaseExternal 3 sqlite3VdbeFreeCursor 6 mozStorageStatement::Execute() 2 mozStorageStatementRow::GetProperty(nsIXPConnectWrappedNative*, 2 mozStorageStatement::~mozStorageStatement() I'll attach more details that might help to focus on anyone of these problems on any one of the two branches. Since it looks like we haven't solved the orginal problem maybe this becomes the tracking bug for many that might be split off.
the sqlite3BtreeParseCellPtr signature in http://people.mozilla.com/~chofmann/crash-data/sqlite-3010-crashes.txt looks like a pretty widespread start up crash with a very high pct of crashes in the first few seconds after launch.
I'm sure we will find at least one topcrash bug out of those lists. adding keywords
Keywords: crash, topcrash
Are we seeing this at all in 1.9.1 or 1.9.2? We have an older version of SQLite on branch that we have upgraded but it hasn't been pushed out yet (see bug 488710).
Keywords: crash, topcrash
Keywords: crash, topcrash
Component: Phishing Protection → Storage
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Product: Firefox → Toolkit
QA Contact: phishing.protection → storage
Depends on: 488710
Version: Trunk → 1.9.0 Branch
the first question is what is "this"? is Alex's orginal [@mozStorageStatement::ExecuteStep(int*)] signature equivalent to the 6 reports for mozStorageStatement::Execute() ? If the anwser is yes, then we are seeing on 1.9.1 and details are here in the form of a startup crash. mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/0d6632c6-6c71-4eb8-b092-b86fa2090513 200905132200 19 60 \N mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/4909948e-1202-43cd-aa6d-b40a62090513 200905132201 10 12 \N mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/63b689c9-89f1-432a-8bc2-8a9ba2090513 200905132159 35 46 \N mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/761fba26-084c-4fae-bd08-5b4482090513 200905132201 10 12 \N mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/8d33512c-89a8-4341-ae3b-73f5c2090513 200905132200 11 43 \N mozStorageStatement::Execute() 0xffffffffffffffff http://crash-stats.mozilla.com/report/index/fd6efe88-76ee-44de-9f9d-250412090513 200905132201 10 14 \N
That looks like a different signature to me. Can we get a new bug filed on that please?
So what does the stack look like for the 1.9.0 orginal bug? There is mention of download related problems but all I can see in the fx3.0.10 data now are two two different choices for that signature. a possible bookmarks related bug 1 mozStorageStatement::ExecuteStep(int*) 0xffffffff80000000 http://crash-stats.mozilla.com/report/index/e4e944af-c26d-47af-9db6-4955c2090512 200905120910 1 18 \N 1 mozStorageStatement::ExecuteStep(int*) 0xffffffff80000000 http://crash-stats.mozilla.com/report/index/4e6a3f5a-ca44-434d-8210-aa3b02090512 200905120909 1 21 \N 1 mozStorageStatement::ExecuteStep(int*) 0xffffffff80000000 http://crash-stats.mozilla.com/report/index/1096b714-a517-4ff5-8660-a53242090512 200905120910 1 8 \N or a possible cookie bug 1 mozStorageStatement::ExecuteStep(int*) 0xae784 http://crash-stats.mozilla.com/report/index/ab756d5d-7abc-470e-ae70-7f9e32090507 200905070512 2 4 \N 1 mozStorageStatement::ExecuteStep(int*) 0xae784 http://crash-stats.mozilla.com/report/index/0fc692f9-4655-402a-bc57-825092090507 200905070512 1 3 \N
I suspect both of those are similar (if not the same crash) as the one this bug is about. The one in comment 15 appears to crash before ExecuteStep is even called. This stacks still appear to be incomplete, which is unfortunate.
Keywords: topcrash
Do we want to tweak the source to get more useful line-number or program-counter variation for interesting cases? Seems like we need something to help us narrow it down. (A person in d-a-f has a classifier.sqlite that crashes him or her, which might be what we need to run it in a debugger. You might even be able to get said person to run in windbg by asking nicely!)
(In reply to comment #19) > Do we want to tweak the source to get more useful line-number or > program-counter variation for interesting cases? Seems like we need something > to help us narrow it down. (A person in d-a-f has a classifier.sqlite that > crashes him or her, which might be what we need to run it in a debugger. You > might even be able to get said person to run in windbg by asking nicely!) I don't even understand why we don't have line numbers now. This is our source code, and the file isn't too long, so we usually get those line numbers.
clearing blocking1.9.0.12 flag, it doesn't look like we understand what problem we're fixing well enough to know whether it's a blocker. A testcase, for any one of those different stacks, would help.
Flags: blocking1.9.0.12?
Keywords: testcase-wanted
Whiteboard: [needs a victim to figure out steps or attach a busted phishing database]
Crash Signature: [@mozStorageStatement::ExecuteStep(int*)]
not much information to debug anything here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Product: Toolkit → Core
You need to log in before you can comment on or make changes to this bug.