568893 - Lots of crashes have nsURLClassifier on the stack

Status: RESOLVED INVALID

(Toolkit :: Safe Browsing, defect)

Description

[Shawn Wilsher :sdwilsh]

I've been looking at a bunch of the topcrashes in SQLite code, and noticed that almost all the time url classifier is on the stack.  The crashes in SQLite don't make sense unless there is memory corruption or something else going horribly wrong.  My concern is that url classifier is doing something slightly off on it's background thread which is causing these crashes.  I'd like us to do one or both of the following solutions:
1) Rewrite the url classifier code to use the asynchronous API in mozStorage.  It's been well tested, and at this point, there aren't any crashers or thread safety bugs on file (or anything involving it on crash-stats as far as I know).  Sadly, this wasn't available when we wrote this in the first place.
2) Rewrite the url classifier code in JavaScript.  It's memory safe, so we will know that it is not at fault for any memory corruption.

Comment 1

[Benjamin Smedberg]

Assuming all-powerful crash-stats knowledge, how would I construct such a query? Any crash with nsUrlClassifier in a frame?

Any SWAG on how this related to other topcrashes?

Comment 2

[[e-mail]]

Can one search for crashes where the string occurs in any frame? Using the string search only turned matched against the first frame for me.

Comment 3

[Shawn Wilsher :sdwilsh]

I just found this out by looking at all the top crashes in SQLite, and started looking at stacks.  Not sure if there is an easy way to check this...

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Not sure what we're being asked to block on here. I can't see us blocking on either of the issues listed in comment 0; is the request to block on investigation?

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #4)
> Not sure what we're being asked to block on here. I can't see us blocking on
> either of the issues listed in comment 0; is the request to block on
> investigation?
It's not a regression really, so probably not blocking.  The blocking request would have been if we needed to block on basically bug 572463.

Comment 6

[Justin Dolske [:Dolske]]

This doesn't seem very actionable to me.