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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[Marcia Knous [:marcia]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Smells like memory corruption of some sort... :(

Comment 3

[Jesse Ruderman]

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

Comment 4

[Jesse Ruderman]

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?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Is this a trunk only problem?

Comment 6

[Martijn Wargers (dead)]

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

Comment 7

[Martijn Wargers (dead)]

Attachment: stack from debug build

Comment 8

[Martijn Wargers (dead)]

I forgot, I had to disable html5 rendering, because it interfered with the page, somehow, causing a blank page.

Comment 9

[Martijn Wargers (dead)]

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.

Comment 10

[Johnny Stenback (:jst)]

Over to bent who will have a look at this...

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 13

[Marcia Knous [:marcia]]

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?

Comment 14

[Marcia Knous [:marcia]]

Martijn: Are you still able to crash on the sites you mention in Comment 9?

Comment 15

[Martijn Wargers (dead)]

No, I can't reproduce those anymore with the latest trunk build.

Comment 16

[Marcia Knous [:marcia]]

marcia will try to reproduce using the branch build tomorrow.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

(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

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We actually need to do both. I don't really know what crazy stuff Windows might do here.

Comment 22

[Marcia Knous [:marcia]]

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.

Comment 23

[Marcia Knous [:marcia]]

http://tinyurl.com/3xmcm7z indicates there were several crashes with the 20100611 build, so apparently people are still hitting it in low volume.

Comment 24

[Jesse Ruderman]

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.

Comment 25

[Damon Sicore (:damons)]

Blocking final here until we have some sort of resolution.

Comment 26

[Marcia Knous [:marcia]]

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.

Comment 27

[Damon Sicore (:damons)]

Do we need to do what Roc says in Comment 21?

Comment 28

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This needs a new owner.

Comment 29

[Damon Sicore (:damons)]

Talking about this more:

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

2) This is wontfix on branches.

Comment 30

[Benjamin Smedberg]

There's nothing to track for Firefox 6 here, mac async painting is going to land for 7.

Comment 31

[Johnny Stenback (:jst)]

Bug 598425 landed in early June, so this is fixed in 7 and beyond!

Comment 32

[u279076]

As per testcase-wanted keyword, is there something QA can do to verify this fix (apart from checking Socorro)?