634387 - [Mac] Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P | mozilla::plugins::PPluginInstanceChild::FatalError ] (was: [@ mozalloc_abort | NS_DebugBreak_P ]) opening a tab with Cmd-T while a Flash video has focus (youtube)

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[d.a.]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre
Build Identifier: 

Report: https://crash-stats.mozilla.com/report/index/bp-e1867b53-1528-429a-990a-17b342110215

I guess this is related to bug 633383. 

Flash will crash if you try to open a new tab when a flash object is focused.

Flash version: 10.1.102.64
Firefox built from: http://hg.mozilla.org/mozilla-central/rev/2c646d10b9c7
Running Firefox in 32-bit mode

Reproducible: Always

Comment 1

[Benjamin Smedberg]

How are you opening the new tab? Can you provide STR as exactly as possible?

Comment 2

[d.a.]

1. I go to a YouTube video, like this one: http://www.youtube.com/watch?v=rLaUVzcyonc
2. Press pause button on player
3. Press cmd+t
4. Flash crashes

The above gave me this report just now: https://crash-stats.mozilla.com/report/index/bp-2a0210f8-84c7-475c-af74-5a9292110215

Comment 3

[Benjamin Smedberg]

I cannot reproduce this with Flash 10.2. Can you upgrade and check?

Comment 4

[d.a.]

You do not need to pause the video actually, only need to make sure the Flash object is focused and then press cmd+t. 

Here are a couple of more reports:
https://crash-stats.mozilla.com/report/index/d158cc5a-374c-4751-acec-dbe4a2110215
https://crash-stats.mozilla.com/report/index/06485297-abd6-4167-a687-112ab2110215

I'll upgrade to 10.2 and check if it happens there too.

Comment 5

[d.a.]

With Flash version: 10.2.152.26 I still get the crash doing the same as before.

Report of one of the crashes here: https://crash-stats.mozilla.com/report/index/1c0db695-51aa-4a2e-8f3c-ac63f2110215

Comment 6

[juan becerra [:juanb]]

I can reproduce the problem as described. You could get into this situation on Mac, for instance, if you go to Netflix and try to play a video which will prompt you to re-install in 32bit mode. Then you follow the steps as described here, and the plug-in will crash:

https://crash-stats.mozilla.com/report/pending/0ebc6536-b423-4063-847d-474432110215

I tried this using the latest, Flash 10.2.152.26 on the latest Minefield on a new Macbook Air

Adapter Description 0x22600,0x20400
Vendor ID0000
Device ID0000
Adapter RAM
Adapter Drivers
Driver Version
Driver Date
Direct2D Enabled false
DirectWrite Enabled false
WebGL RendererNVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine -- 2.1 NVIDIA-1.6.24
GPU Accelerated Windows 0/2

Comment 7

[Benjamin Smedberg]

I wonder if this crash is non-accelerated only, because I still cannot reproduce. Let me try disabling and see whether that changes things.

Comment 8

[Benjamin Smedberg]

Hrm, no. In Flash settings, is "Enable hardware acceleration" checked?

Comment 10

[Parker]

To anyone who cannot reproduce this, run Firefox in 32-bit mode. For me, the issue does not occur when Firefox is run in 64 bit mode.

https://crash-stats.mozilla.com/report/index/d79bb90e-8238-4a87-9111-655c92110216
https://crash-stats.mozilla.com/report/index/398e8503-1ea9-4315-ae98-a976b2110216

Comment 11

[Benjamin Smedberg]

I cannot reproduce this in 64 or 32-bit mode, Flash accel on or off, and Firefox accel on or off. :-( I'd really like help narrowing down the set of circumstances where this occurs.

Comment 12

[Parker]

It always happens for me in Youtube, (obviously with HTML5 mode disabled). It also happened for me in safe mode. 

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11)
Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11)
Gecko/20100101 Firefox/4.0b11

I'm running Mac OS X 10.6

Comment 13

[Marcia Knous [:marcia]]

Like Parker, I can reproduce this on my Macbook but only in 32 bit mode running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre.

Adapter Description0x24200,0x20400
Vendor ID0000Device ID0000
Adapter RAM
Adapter Drivers
Driver Version 
Driver Date
Direct2D Enabled false
DirectWrite Enabled false
WebGL RendererIntel Inc. -- Intel GMA X3100 OpenGL Engine -- 2.0 APPLE-1.6.26
GPU Accelerated Windows0/1

Comment 14

[juan becerra [:juanb]]

Responding to comment #8, my Flash settings are set to "enable hardware acceleration."

Comment 15

[Josh Aas]

I can repro if I start in 32-bit mode ("arch -i386 /Applications/Minefield.app/Contents/MacOS/firefox-bin"). Flash 10.2.152.26, latest Minefield nightly on Mac OS X 10.6.6.

I get this for output:

[josh@earth mozilla-central] arch -i386 /Applications/Minefield.app/Contents/MacOS/firefox-bin 
###!!! ABORT: [PPluginInstanceChild] abort()ing as a result: file PPluginInstanceChild.cpp, line 2167
###!!! ABORT: [PPluginInstanceChild] abort()ing as a result: file PPluginInstanceChild.cpp, line 2167
###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv
###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv
###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv
###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv
###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv
###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv

Comment 16

[Johnathan Nightingale [:johnath]]

per bsmedberg on the daily driver call

Comment 17

[(no longer active)]

Stepping into plugin land!

Comment 18

[(no longer active)]

The key to reproducing this seems to be opening the new tab very quickly after pressing pause.

Comment 19

[(no longer active)]

bp-7d60504a-8c1d-43f0-85ad-d66fd2110216 is what I got.

ehsanakhgari:~/moz/mozilla-central [02:49:17]$ ###!!! ABORT: [PPluginInstanceChild] abort()ing as a result: file PPluginInstanceChild.cpp, line 2167
###!!! ABORT: [PPluginInstanceChild] abort()ing as a result: file PPluginInstanceChild.cpp, line 2167

###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv


###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv


###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv


###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv


###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv


###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv

Comment 20

[Parker]

In response to comment 18 , this issue arises for me regardless of how long the video has been running. It also happens on embedded videos, and for sites like http://sharingtbh.com/ckme2gy4u9ul that use flash to play audio.

Comment 21

[(no longer active)]

(In reply to comment #20)
> In response to comment 18 , this issue arises for me regardless of how long the
> video has been running. It also happens on embedded videos, and for sites like
> http://sharingtbh.com/ckme2gy4u9ul that use flash to play audio.

I was not talking about opening the new tab right after the video has started.  I was talking about opening the new tab immediately after pressing the pause button in the video, no matter how long it's been playing.

Comment 22

[Parker]

(In reply to comment #21)

What I mean is that, at least in my case, the issue still occurs even when the pause button has never been pressed. No matter what I do, opening a new tab will crash the plugin. 

Interestingly, using the New Tab command from the menu won't crash it. Could it have something to do with Flash and Firefox fighting for who gets priority on key presses?

Comment 23

[Parker]

Just an update (sorry to keep spamming all of your inboxes!):

The crash doesn't happen if you click somewhere on the page away from the actual flash content. So if pause the video, then open a new tab, it crashes. If you click somewhere else on the page first though, it doesn't.

Comment 24

[(no longer active)]

Here is part of the problem.  The parent process get this assertion on the keyup event:

###!!! ASSERTION: Attempted to serialize unknown event type.: 'Not Reached', file ../../dist/include/mozilla/plugins/NPEventOSX.h, line 110
<http://mxr.mozilla.org/mozilla-central/source/dom/plugins/NPEventOSX.h#110>

And subsequently the child process gets this assertion, which leads to its demise:

###!!! ASSERTION: Attempted to de-serialize unknown event type.: 'Not Reached', file ../../dist/include/mozilla/plugins/NPEventOSX.h, line 206
<http://mxr.mozilla.org/mozilla-central/source/dom/plugins/NPEventOSX.h#206>

Here is the call stack in the parent process:

(gdb) bt 10
#0  IPC::ParamTraits<mozilla::plugins::NPRemoteEvent>::Write (aMsg=0x2fd136e0, aParam=@0xbfffdcc4) at NPEventOSX.h:110
#1  0x0155c63b in IPC::WriteParam<mozilla::plugins::NPRemoteEvent> (m=0x2fd136e0, p=@0xbfffdcc4) at ipc_message_utils.h:124
#2  0x0156bbb7 in mozilla::plugins::PPluginInstanceParent::Write<mozilla::plugins::NPRemoteEvent> (this=0x268de420, __v=@0xbfffdcc4, __msg=0x2fd136e0) at PPluginInstanceP
arent.h:534
#3  0x0155d513 in mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent (this=0x268de420, event=@0xbfffdcc4, handled=0xbfffdd2e) at PPluginInstanceParent.cpp:379
#4  0x0151cc78 in mozilla::plugins::PluginInstanceParent::NPP_HandleEvent (this=0x268de420, event=0xbfffe774) at /Users/ehsanakhgari/moz/mozilla-central/dom/plugins/Plugi
nInstanceParent.cpp:987
#5  0x01525baf in mozilla::plugins::PluginModuleParent::NPP_HandleEvent (instance=0x51b037c, event=0xbfffe774) at /Users/ehsanakhgari/moz/mozilla-central/dom/plugins/Plug
inModuleParent.cpp:531
#6  0x0124848a in nsNPAPIPluginInstance::HandleEvent (this=0x51b0370, event=0xbfffe774, result=0xbfffdece) at /Users/ehsanakhgari/moz/mozilla-central/modules/plugin/base/
src/nsNPAPIPluginInstance.cpp:581
#7  0x0043a992 in nsPluginInstanceOwner::ProcessEvent (this=0x1f152110, anEvent=@0xbfffe6e4) at /Users/ehsanakhgari/moz/mozilla-central/layout/generic/nsObjectFrame.cpp:5
066
#8  0x0043b884 in nsPluginInstanceOwner::DispatchKeyToPlugin (this=0x1f152110, aKeyEvent=0x1f9f3d80) at /Users/ehsanakhgari/moz/mozilla-central/layout/generic/nsObjectFra
me.cpp:4396
#9  0x0043ba9c in nsPluginInstanceOwner::KeyUp (this=0x1f152110, aKeyEvent=0x1f9f3d80) at /Users/ehsanakhgari/moz/mozilla-central/layout/generic/nsObjectFrame.cpp:4329

aParam.event.type is 0x37000004, which is completely meaningless.  So I dug down further.  Here is the problem.

In PluginInstanceOwner::ProcessEvent, we set the event variable to the pluginEvent member here: <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#4958>.  pluginEvent's type is NPEvent, aka EventRecord.  If pluginEvent is null (which it's not in this case), we may set the event variable to point to an NPCocoaEvent object (synthCocoaEvent).  Note that this is a completely incompatible type to EventRecord.  So, in frame 7, we call mInstance->HandleEvent with event pointing to an EventRecord.

Frames 6 and 5 treat event as an opaque void*, and we reach down to frame 4.  Here, on Mac, we cast event to an NPCocoaEvent* unconditionally <http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceParent.cpp#809>, and later on in frame 7 when we try to read the type member, we'll be reading a random part in the guts of the EventRecord object.

Here's the real and masked identity of our object at frame 4:

Real identity:
(gdb) p *(EventRecord*)event
$27 = {
  what = 4,
  message = 14080,
  when = 14469195,
  where = {
    v = 636,
    h = 161
  },
  modifiers = 0
}

Masked identity:
(gdb) p *(NPCocoaEvent*)event
$28 = {
  type = 922746884,
  version = 3360358400,
  data = {
    mouse = {
      modifierFlags = 41681116,
      pluginX = 7.9544568980440694e-322,
      pluginY = 8.754045822690683e-163,
      buttonNumber = 21224862,
      clickCount = 508114080,
      deltaX = 1.4490278955182641e-302,
      deltaY = 4.2651927272129217e-299,
      deltaZ = 2.7366945127779023e-315
    },
    key = {
      modifierFlags = 41681116,
      characters = 0xa1,
      charactersIgnoringModifiers = 0x0,
      isARepeat = 132 '',
      keyCode = 0 
    },
    draw = {
      context = 0x27c00dc,
      x = 7.9544568980440694e-322,
      y = 8.754045822690683e-163,
      width = 8.754045848879431e-163,
      height = 1.4490278955182641e-302
    },
    focus = {
      hasFocus = 220 ''
    },
    text = {
      text = 0x27c00dc
    }
  }
}


As far as I can tell, this bug exists in any situation where pluginEvent is not null in PluginInstanceOwner::ProcessEvent.

Comment 25

[(no longer active)]

And here is where pluginEvent is coming from.  <http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsChildView.mm#5768>

I'm not really sure what the best approach to fixing this bug would be though.

Comment 26

[(no longer active)]

Josh, bsmedberg, any insights on this?

Comment 27

[Josh Aas]

I can look into this tomorrow.

Comment 28

[(no longer active)]

(In reply to comment #27)
> I can look into this tomorrow.

Thanks!

/me eagerly watches here to see what the patch looks like

Comment 29

[Benjamin Smedberg]

Scoobidiver, *this* bug is Mac-only. If you are seeing something like this on other platforms, it needs a different bug.

Comment 31

[Mike Shaver (:shaver emeritus)]

Josh: any insight so far?

Comment 32

[Josh Aas]

Attachment: fix v1.0

When a plugin has focus and the user hits cmd-t, the key down changes focus to another view. I think this is the view for the URL bar because focus clearly gets there eventually, but this crash could happen while focus is briefly held by an intermediate view. The main point is it is another non-plugin view. This non-plugin view will eventually receive a flag-changed event for the cmd key going up. There is no check for whether or not a view is a plugin view in the flag-changed event generation code, so it attached an NPAPI event of the default type, Carbon, to the generated Gecko event. Somehow that was making its way to the plugin and we'd choke trying to interpret it as a Cocoa NPAPI event.

I don't know why the Gecko event generated by the non-plugin (url bar?) view ended up getting sent to the plugin view but not attaching any NPAPI event in a non-plugin view fixes the problem. This is probably the right thing to do, but it might be enlightening to have an explanation for how the event got there in the first place.

Comment 33

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 513714 [details] [diff] [review]
fix v1.0

Makes sense to me.

Comment 34

[Mike Shaver (:shaver emeritus)]

http://hg.mozilla.org/mozilla-central/rev/97625b507157

Comment 35

[Josh Aas]

That patch didn't go through try server yet, hope it works out!

Comment 37

[Scoobidiver (away)]

It crashes in 4.0b13pre/20110225: bp-dae98052-85a3-4cb9-8231-839f12110225.

Comment 38

[Josh Aas]

The new crash from comment 37 might be another bad message being processed in the child process but I'm pretty sure it isn't the same bug as this. The cmd-t bug was easily reproducible and it is gone now as far as I can tell. We should file another bug for the new crash. Until we have a parent stack or some repro steps we have no way to know what message is being processed.

Comment 39

[Maniac Vlad Florin (:vladmaniac)]

Verified Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0