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

Status: RESOLVED INCOMPLETE

(Toolkit :: Storage, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

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

[Dietrich Ayala (:dietrich)]

switching to DM per the crash report

Comment 2

[Dietrich Ayala (:dietrich)]

(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

[Ed Lee :Mardak]

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?

Comment 4

[Reed Loden [:reed]]

(In reply to comment #3)
> Is the frame information right?

The url-classifier stuff is on another thread, so breakpad probably got confused. :(

Comment 5

[(not currently active) Ted Mielczarek]

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.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

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

[Martijn Wargers (dead)]

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

Comment 8

[(not currently active) Ted Mielczarek]

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

[Martijn Wargers (dead)]

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.

Comment 10

[chris hofmann]

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

[chris hofmann]

http://people.mozilla.com/~chofmann/crash-data/sqlite-3010-crashes.txt
http://people.mozilla.com/~chofmann/crash-data/mozStorage-3010-crashes.txt

http://people.mozilla.com/~chofmann/crash-data/sqlite-35b4-crashes.txt
http://people.mozilla.com/~chofmann/crash-data/mozStorage-35b4-crashes.txt

Comment 12

[chris hofmann]

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

[chris hofmann]

I'm sure we will find at least one topcrash bug out of those lists.   adding keywords

Comment 14

[Shawn Wilsher :sdwilsh]

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).

Comment 15

[chris hofmann]

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

[Shawn Wilsher :sdwilsh]

That looks like a different signature to me.  Can we get a new bug filed on that please?

Comment 17

[chris hofmann]

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

[Shawn Wilsher :sdwilsh]

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

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[Shawn Wilsher :sdwilsh]

(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

[Daniel Veditz [:dveditz]]

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.

Comment 22

[Marco Bonardo [:mak]]

not much information to debug anything here.