Closed Bug 1137343 Opened 6 years ago Closed 6 years ago

crash in XPCWrappedNative::AddRef() while calling AsyncStatement::cleanupJSHelpers()

Categories

(Toolkit :: Storage, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox36 + wontfix
firefox37 + fixed
firefox38 + fixed
firefox39 + fixed

People

(Reporter: kairo, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, topcrash)

Crash Data

[Tracking Requested - why for this release]:

This bug was filed from the Socorro interface and is 
report bp-33b858b8-a125-4ff0-8440-15a512150220.
=============================================================

Top frames:
 	xul.dll 	XPCWrappedNative::AddRef() 	js/xpconnect/src/XPCWrappedNative.cpp
1 	xul.dll 	XPCWrappedNative::QueryInterface(nsID const&, void**) 	js/xpconnect/src/XPCWrappedNative.cpp
2 	xul.dll 	nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) 	xpcom/glue/nsCOMPtr.cpp
3 	xul.dll 	nsCOMPtr<nsIXPConnectWrappedNative>::nsCOMPtr<nsIXPConnectWrappedNative>(nsQueryInterface) 	xpcom/glue/nsCOMPtr.h
4 	xul.dll 	mozilla::storage::AsyncStatement::cleanupJSHelpers() 	storage/src/mozStorageAsyncStatement.cpp
5 	xul.dll 	mozilla::storage::AsyncStatement::~AsyncStatement() 	storage/src/mozStorageAsyncStatement.cpp
6 	xul.dll 	mozilla::storage::AsyncStatement::Release() 	storage/src/mozStorageAsyncStatement.cpp
7 	xul.dll 	mozilla::storage::StatementData::~StatementData() 	storage/src/mozStorageStatementData.h
8 	xul.dll 	mozilla::storage::AsyncExecuteStatements::notifyComplete() 	storage/src/mozStorageAsyncStatementExecution.cpp
9 	xul.dll 	mozilla::storage::AsyncExecuteStatements::Run() 	storage/src/mozStorageAsyncStatementExecution.cpp
10 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp

Those crashes show up at #5 with 1.7% of all crashes in early 36 release data, they seem to be around in decent volume in newer prereleases as well but not in 35 or older.

They all have an address of 0x0, so smelling like a null deref, there's not much more than storage code in the stacks, and I do not see any interesting correlations to either DLLs or add-ons. The crashes happen on all Windows versions, from XP up to at least 8.1 but not on Linux or Mac (yet).

URLs are mostly about:home and about:newtab, followed by random sites, as usual led by Facebook, so it sounds like it's not triggered by website stuff but something on our side.

For more stats and reports, see https://crash-stats.mozilla.com/report/list?signature=XPCWrappedNative%3A%3AAddRef%28%29
The |TlsGetValue| call for |sCollectorData| came back null. Andrew, have you seen this before?
Flags: needinfo?(continuation)
Somebody is using a cycle collected object off the main thread.
Flags: needinfo?(continuation)
Topcrash, tracking.
This is (security) bug 1005991 which has a fix that needs a little more love.  I'm not sure if I should dupe it given the crash signature and that it's a top-crash.
Depends on: 1005991
[Tracking Requested - why for this release]:
The crash signature of this bug is #11 with ~1.3% of all 37.0b3 crashes, I think we should track for this train as well.
I'll track this for the reason stated above. We need someone to pickup bug 1005991 if this is going to be fixed in 37.
Note that on 36.0.1, i.e. on our release population, this currently is even higher, at #3 with 24% of all crashes.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7)
> Note that on 36.0.1, i.e. on our release population, this currently is even
> higher, at #3 with 24% of all crashes.

I looked at a dozen or so of these crashes and they all looked like bug 1005991.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7)
> Note that on 36.0.1, i.e. on our release population, this currently is even
> higher, at #3 with 24% of all crashes.

I assume that was meant to be 2.4%!
(In reply to :dmajor (semi-away, use needinfo) from comment #9)
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7)
> > Note that on 36.0.1, i.e. on our release population, this currently is even
> > higher, at #3 with 24% of all crashes.
> 
> I assume that was meant to be 2.4%!

Yes, sorry. What a missing decimal point can change. ;-)
Summary: crash in XPCWrappedNative::AddRef() → crash in XPCWrappedNative::AddRef() while calling AsyncStatement::cleanupJSHelpers()
Looking at crash-stats from discussion with Lawrence this afternoon. This is still the #12 crash for 37.0b7 with 462 crashes in the last week, 1.1% of all beta7 crashes. 

Oddly, this is showing up on the signature report at https://crash-stats.mozilla.com/report/list?signature=XPCWrappedNative%3A%3AAddRef%28%29 with signatures for 37.0b7, but not in supersearch if you put in 37.0b7 as a parameter.    On the first search (which looks for the signature in any version of Firefox) it also shows up about half the time as a startup crash.
Keywords: topcrash
(In reply to Liz Henry (:lizzard) from comment #11)
> but not in supersearch if you put in 37.0b7 as a parameter.

Supersearch does not support the beta version numbers as parameters at this time. You need to search for 37.0 + beta channel + Build ID.
Bug 1005991 has landed on Beta, Aurora, and Nightly. Resolving this bug as fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1116067
You need to log in before you can comment on or make changes to this bug.