Closed Bug 423943 Opened 14 years ago Closed 7 years ago

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

Categories

(Toolkit :: Storage, 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: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.