Closed Bug 552002 Opened 14 years ago Closed 13 years ago

Crash in [@ nsDOMEvent::QueryInterface(nsID const&, void**) ]

Categories

(Core Graveyard :: Plug-ins, defect)

1.9.2 Branch
defect
Not set
critical

Tracking

(firefox5- wontfix, firefox6- wontfix, firefox7+ fixed, firefox8+ fixed, blocking2.0 -, status2.0 wontfix, status1.9.2 wontfix, status1.9.1 wontfix)

RESOLVED FIXED
Tracking Status
firefox5 - wontfix
firefox6 - wontfix
firefox7 + fixed
firefox8 + fixed
blocking2.0 --- -
status2.0 --- wontfix
status1.9.2 --- wontfix
status1.9.1 --- wontfix

People

(Reporter: marcia, Unassigned)

References

()

Details

(Keywords: crash, Whiteboard: [sg:critical?][to be fixed by asynchronous plugin painting][qa?])

Crash Data

Attachments

(1 file)

Seen while reviewing crash data and 100% reproducible on the site in the URL using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a3pre) Gecko/20100312 Minefield/3.7a3pre

STR:
1. Load site in URL
2. Perform and right click event and then scroll. Crash.

https://crash-stats.mozilla.com/report/index/36fa4e87-e61f-42cc-abce-b6cc92100312
https://crash-stats.mozilla.com/report/index/762c0b32-8f02-4c28-9f83-ac3852100312
https://crash-stats.mozilla.com/report/index/bp-85a1d79c-5fb1-4364-9e00-b14092100312

are my three crash reports and my flash version is below.

    File: Flash Player.plugin
    Version: 10.1.51.95
    Shockwave Flash 10.1 d51
I am able to reproduce the crash on Windows using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a3pre) but I do get a completely different stack than Mac: http://crash-stats.mozilla.com/report/index/32439b8a-6242-44dc-922d-4291c2100312 where I crash in  [@ _filbuf ]. 

Version: 10.0.45.2
Shockwave Flash 10.0 r45
OS: Mac OS X → All
Hardware: x86 → All
Smells like memory corruption of some sort... :(
Whiteboard: [sg:investigate]
We're not using [sg:investigate] any more.  Please use [sg:critical] or [sg:critical?] for scary crashes with testcases, like this one.

(There's no special marking for "this crash would be scary if it had a testcase".  We want those bugs to be public to give them a shot at being fixed, but we don't want to draw too much evil attention to them.)
Group: core-security
Keywords: testcase-wanted
Whiteboard: [sg:investigate] → [sg:critical?]
I'm having trouble reproducing on Mac OS X 10.5.  Which is sad, because it's a platform where Valgrind works, and Valgrind is good at tracking down the source of memory corruption.

Am I supposed to right-click on the Flash?  And then scroll with the mouse wheel / trackpad?  While the context menu is still up?
Is this a trunk only problem?
I can reproduce this, I haven't been able to reproduce this in a 2010-03-11 build. There I get flash context menus that get 'stuck' and a Minefield that is basically unusable.

In a debug build, I see this in a debug build before the crash
###!!! ASSERTION: Adding a script runner when that is prevented!: 'Error', file
c:/mozilla-build/src/content/base/src/nsContentUtils.cpp, line 4599
Attached file stack from debug build —
I forgot, I had to disable html5 rendering, because it interfered with the page, somehow, causing a blank page.
I'm seeing these crashes too on http://www.vanderaa.net/afterlife-video-trailer
When right-clicking on one of the "audio excerpts" flash things (they are also flashing in a weird way, I suspect that is a direct2d bug of some sort).

I also managed once to crash with a different stack on that site:
http://crash-stats.mozilla.com/report/index/bp-19419c7f-f8ea-42d8-a7ac-b653a2100314
I think (tentative) steps to reproduce: right-click on the main video, then minimize window, then close tab or something.
Over to bent who will have a look at this...
Assignee: nobody → bent.mozilla
This looks like a bug in plugin code, not in DOM events.
But feel free to change back the component and assign this bug to me if 
the bug is somewhere in events code.
Component: DOM: Events → Plug-ins
QA Contact: events → plugins
I think this is going to end up a dup of bug 535651 or bug 449129. In this case I think we're running NPRuntime stuff inside a paint.
I cannot reproduce this using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3, but it easily reproduced on the trunk nightly.

(In reply to comment #5)
> Is this a trunk only problem?
Martijn: Are you still able to crash on the sites you mention in Comment 9?
No, I can't reproduce those anymore with the latest trunk build.
Whiteboard: [sg:critical?] → [sg:critical?][critsmash:investigating]
marcia will try to reproduce using the branch build tomorrow.
(In reply to comment #6)
> In a debug build, I see this in a debug build before the crash
> ###!!! ASSERTION: Adding a script runner when that is prevented!: 'Error', file
> c:/mozilla-build/src/content/base/src/nsContentUtils.cpp, line 4599

Jonas, Roc, I never really understood why nsContentUtils::AddScriptBlockerAndPreventAddingRunners()
is ok.
The assertion was added in http://hg.mozilla.org/mozilla-central/rev/9584d6bce9c1
IIRC the idea was that it marks a section where we really should never be adding any script runners. I.e. a section where script blockers technically shouldn't even be needed.

However if we get something wrong and do accidentally attempt to add a scriptrunner, then we'll simply not run the runner. In an attempt to avoid exploitable crashes. I.e. we're attempting to turn an exploitable crash into a mere broken functionality.
That's part of the truth.

See
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#1740

The main reason is that blocking script execution suppresses flushing in nsPresShell, so we want to be able to add a script blocker to do that, but we want to be able to remove that blocker at a time when it is actually not safe to run scripts.
Roc, if the main purpose is to suppress flushing, not suppress scripts, then would it make sense to instead add a flag to nsPresShell which disabled flushing and temporarily set that?
We actually need to do both. I don't really know what crazy stuff Windows might do here.
I cannot reproduce this issue using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4 or the equivalent Windows 3.6.4 version.

(In reply to comment #16)
> marcia will try to reproduce using the branch build tomorrow.
Depends on: 449129
Whiteboard: [sg:critical?][critsmash:investigating] → [sg:critical?][critsmash:depends on 449129]
Whiteboard: [sg:critical?][critsmash:depends on 449129] → [sg:critical?][critsmash:investigating] depends on bug 449129
http://tinyurl.com/3xmcm7z indicates there were several crashes with the 20100611 build, so apparently people are still hitting it in low volume.
Did the fix for bug 449129 take care of this case?  Note that you'll still experience the plugin bug as a crash, but it will be a safe NS_RUNTIMEABORT in RPCChannel::SpinInternalEventLoop rather than a possibly exploitable crash in some random DOM code.
Blocking final here until we have some sort of resolution.
blocking2.0: --- → final+
The site in the URL has changed quite a bit since the initial crash and I am not able to crash using either Windows or Mac latest trunk nightly.

Of late, the 3.6.x branch is showing 23 Windows crashes - http://tinyurl.com/234c4ls, but the branch does not have the patch in Bug 449129 yet.
Whiteboard: [sg:critical?][critsmash:investigating] depends on bug 449129 → [sg:critical?][critsmash:investigating] waiting for firefox 4 to ship to get data to decide whether to take a branch fix
Depends on: 591409
Do we need to do what Roc says in Comment 21?
blocking2.0: final+ → ---
Whiteboard: [sg:critical?][critsmash:investigating] waiting for firefox 4 to ship to get data to decide whether to take a branch fix → [sg:critical?][critsmash:investigating][1.9.2 branch and older] waiting for firefox 4 to ship to get data to decide whether to take a branch fix
Version: Trunk → 1.9.2 Branch
This needs a new owner.
Assignee: bent.mozilla → nobody
Whiteboard: [sg:critical?][critsmash:investigating][1.9.2 branch and older] waiting for firefox 4 to ship to get data to decide whether to take a branch fix → [sg:critical?][critsmash:investigating][1.9.2 branch and older][waiting on async plugins]waiting for firefox 4 to ship to get data to decide whether to take a branch fix
Talking about this more:

1) This is to be fixed by async plugin painting,

2) This is wontfix on branches.
Whiteboard: [sg:critical?][critsmash:investigating][1.9.2 branch and older][waiting on async plugins]waiting for firefox 4 to ship to get data to decide whether to take a branch fix → [sg:critical?][to be fixed by asynchronous plugin painting]
blocking2.0: --- → -
Depends on: 598425
There's nothing to track for Firefox 6 here, mac async painting is going to land for 7.
Crash Signature: [@ nsDOMEvent::QueryInterface(nsID const&, void**) ]
Bug 598425 landed in early June, so this is fixed in 7 and beyond!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
As per testcase-wanted keyword, is there something QA can do to verify this fix (apart from checking Socorro)?
Whiteboard: [sg:critical?][to be fixed by asynchronous plugin painting] → [sg:critical?][to be fixed by asynchronous plugin painting][qa?]
Group: core-security
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.