Closed Bug 985922 Opened 10 years ago Closed 10 years ago

Firefox 27.0.1 startup crash in memcpy | fill_window with BitGuard

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox28 + affected
firefox29 + fixed

People

(Reporter: kairo, Unassigned)

Details

(Keywords: crash, topcrash-win)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-bbe607b6-5e6b-4499-b792-a5e3f2140320.
=============================================================

Since Firefox 28 was released, we have a really high spike of crashes in 27 that seem to happen with some JS compression stuff and zlib, find more crashes at https://crash-stats.mozilla.com/report/list?signature=memcpy%20%7C%20fill_window

Correlations say the following:
    100% (27004/27107) vs.  22% (30108/137161) BitGuard.dll

I stopped reading there...

We blocklisted BitGuard in bug 925459 but AFAIK that block might not actually work in 27 due to not having David's ingenious blocklisting rework in place yet.

I'm not sure what to do there, but the spiking signatures together make up about 20% of the total 27.0.1 crash report volume in yesterday's data (and by total, I mean browser+plugin crash+hang reports).
This must have been triggered by the "updates are available" codepath.

The main thread is compiling http://mxr.mozilla.org/mozilla-release/source/toolkit/mozapps/extensions/content/extensions-content.js (which does look like it relates to updates) and is waiting on a source compression task thread. Bitguard has hooked mozjs!JS::Compile so maybe they've done something to that stream.

I see a single hit on 28, and it's from the beta channel, so I imagine that the user was being offered 29.0b1. This suggests that we may see this problem again at the transition from 28 release -> 29 release.

If bug 951827 sticks on beta (still remains to be seen) then we should be able to start blocking bitguard starting in 29. Otherwise we may want to look into temporary solutions (maybe rename Compile to break the hook?).
In that case I want to track this for 29 so we're aware closer to the shipping of 29 if we need to act here.
status-firefox29: --- → affected
tracking-firefox29: --- → +
We may see this once more at the release of 29 (since 28 is affected) but I expect that to be the last occurrence. It looks like 951827 will stick and 29 will block bitguard.
David, are you going to consider temporary solutions for 29 (as said in comment #1)? or should I untrack it? Thanks
Flags: needinfo?(dmajor)
Sylvestre, comment 3 already says that this should be fixed for 29 because the blocklist bug 951827 is done.
Flags: needinfo?(dmajor)
OK. Thanks! Updating the tracking flag then.
status-firefox29: affected → fixed
The absolute numbers of crash counts barely are going down even though ADI on 27 have been dropping steadily. This sounds like people would not be able to update.
Unfortunately, this happens at startup, so it's probably hard to find a way to get people actually updated.

The "Crashes Per Install" section on the signature summary for https://crash-stats.mozilla.com/report/list?signature=memcpy%20%7C%20fill_window suggests that this happened to ~25,000 installations in the last week.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7)
> The "Crashes Per Install" section on the signature summary for
> https://crash-stats.mozilla.com/report/
> list?signature=memcpy%20%7C%20fill_window suggests that this happened to
> ~25,000 installations in the last week.

A week later, it's still 20,000. And 29 is coming in two weeks. Let's see how hard it hits 28, then - thankfully, 29 itself will be immune to it, thanks to the awesome blocklisting improvements that David got into that one!
And, just as a last update before we ship 29 on what we see with 27 here: Over the last week, we still had a bit over 15,000 installations seeing this startup crash.
The good news here is that it doesn't seem like 28 has any kind of significant crash here since 29 has been released, I guess the users that are seeing this are just stuck and never got to a working 28 anyhow.

Given that the BitGuard block works in 29 and we don't seem interested to fix this for the remaining 27 users, I'm calling this bug WONTFIX.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10)
> [...]we don't seem interested to fix this for the remaining 27 users[...]

Or, better, not able to fix this in any conventional form and without a good idea how we could do it otherwise.
You need to log in before you can comment on or make changes to this bug.