Closed
Bug 423943
Opened 17 years ago
Closed 10 years ago
Repeated crash [@mozStorageStatement::ExecuteStep(int*)]
Categories
(Core :: SQLite and Embedded Database Bindings, defect)
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?
Comment 1•17 years ago
|
||
switching to DM per the crash report
Component: Places → Download Manager
QA Contact: places → download.manager
Comment 2•17 years ago
|
||
(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.
Comment 3•17 years ago
|
||
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
Comment 4•17 years ago
|
||
(In reply to comment #3)
> Is the frame information right?
The url-classifier stuff is on another thread, so breakpad probably got confused. :(
Updated•17 years ago
|
Component: Download Manager → Phishing Protection
QA Contact: download.manager → phishing.protection
Version: unspecified → Trunk
Comment 5•17 years ago
|
||
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.
Reporter | ||
Comment 6•17 years ago
|
||
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.
Comment 7•16 years ago
|
||
Any update on this?
This might be nr. 26 and nr. 49 in current topcrashes for Firefox 3.0.
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=sqlite3GetVarint32
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=sqlite3BtreeParseCellPtr
Severity: normal → critical
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Comment 8•16 years ago
|
||
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.
Comment 9•16 years ago
|
||
The memcpy crash seems to also be related to this:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=memcpy%20%7C%20fillInCell
And that one is nr. 13 in the topcrash list.
Flags: blocking1.9.0.12?
Comment 10•16 years ago
|
||
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.
Comment 11•16 years ago
|
||
Comment 12•16 years ago
|
||
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.
Comment 13•16 years ago
|
||
I'm sure we will find at least one topcrash bug out of those lists. adding keywords
Comment 14•16 years ago
|
||
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).
Updated•16 years ago
|
Updated•16 years ago
|
Component: Phishing Protection → Storage
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Product: Firefox → Toolkit
QA Contact: phishing.protection → storage
Updated•16 years ago
|
Version: Trunk → 1.9.0 Branch
Comment 15•16 years ago
|
||
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
Comment 16•16 years ago
|
||
That looks like a different signature to me. Can we get a new bug filed on that please?
Comment 17•16 years ago
|
||
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
Comment 18•16 years ago
|
||
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.
Comment 19•16 years ago
|
||
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!)
Comment 20•16 years ago
|
||
(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.
Comment 21•16 years ago
|
||
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
Updated•15 years ago
|
Whiteboard: [needs a victim to figure out steps or attach a busted phishing database]
Assignee | ||
Updated•14 years ago
|
Crash Signature: [@mozStorageStatement::ExecuteStep(int*)]
Comment 22•10 years ago
|
||
not much information to debug anything here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Updated•9 years ago
|
Keywords: testcase-wanted
Updated•6 months ago
|
Product: Toolkit → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•