Closed Bug 634387 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Plug-ins, defect, critical)

All
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: danne.da, Assigned: jaas)

References

()

Details

(Keywords: crash, reproducible, Whiteboard: [hardblocker])

Crash Data

Attachments

(1 file)

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
How are you opening the new tab? Can you provide STR as exactly as possible?
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
I cannot reproduce this with Flash 10.2. Can you upgrade and check?
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.
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
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
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: crash, reproducible
I wonder if this crash is non-accelerated only, because I still cannot reproduce. Let me try disabling and see whether that changes things.
Hrm, no. In Flash settings, is "Enable hardware acceleration" checked?
Duplicate of this bug: 634611
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
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.
Keywords: qawanted
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
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
Responding to comment #8, my Flash settings are set to "enable hardware acceleration."
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
per bsmedberg on the daily driver call
Assignee: nobody → joshmoz
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Stepping into plugin land!
Assignee: joshmoz → ehsan
The key to reproducing this seems to be opening the new tab very quickly after pressing pause.
Keywords: qawanted
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
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.
(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.
(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?
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.
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.
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.
Josh, bsmedberg, any insights on this?
I can look into this tomorrow.
(In reply to comment #27)
> I can look into this tomorrow.

Thanks!

/me eagerly watches here to see what the patch looks like
Assignee: ehsan → joshmoz
OS: Mac OS X → All
Hardware: x86 → All
Summary: [Mac] Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P] → [Mac] Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P][@ mozalloc_abort(char const* const) | NS_DebugBreak_P ]
Version: unspecified → Trunk
Summary: [Mac] Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P][@ mozalloc_abort(char const* const) | NS_DebugBreak_P ] → Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P][@ mozalloc_abort(char const* const) | NS_DebugBreak_P ]
Scoobidiver, *this* bug is Mac-only. If you are seeing something like this on other platforms, it needs a different bug.
OS: All → Mac OS X
Summary: Firefox 4.0b12pre crash [@ mozalloc_abort | NS_DebugBreak_P][@ mozalloc_abort(char const* const) | NS_DebugBreak_P ] → [Mac] Firefox 4.0b12pre crash in mozilla::plugins::PPluginInstanceChild::FatalError [@ mozalloc_abort | NS_DebugBreak_P]
Severity: normal → critical
Duplicate of this bug: 632730
Summary: [Mac] Firefox 4.0b12pre crash in mozilla::plugins::PPluginInstanceChild::FatalError [@ mozalloc_abort | NS_DebugBreak_P] → [Mac] Firefox 4.0b12pre crash in mozilla::plugins::PPluginInstanceChild::FatalError [@ mozalloc_abort | NS_DebugBreak_P] opening a tab with Cmd-T while a Flash video has focus (youtube)
Attached patch fix v1.0Splinter Review
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.
Attachment #513714 - Flags: review?(smichaud)
Whiteboard: [hardblocker] → [hardblocker][has patch]
Comment on attachment 513714 [details] [diff] [review]
fix v1.0

Makes sense to me.
Attachment #513714 - Flags: review?(smichaud) → review+
Keywords: checkin-needed
Whiteboard: [hardblocker][has patch] → [hardblocker][has patch][needs landing]
http://hg.mozilla.org/mozilla-central/rev/97625b507157
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch][needs landing] → [hardblocker][has patch]
That patch didn't go through try server yet, hope it works out!
Duplicate of this bug: 593467
It crashes in 4.0b13pre/20110225: bp-dae98052-85a3-4cb9-8231-839f12110225.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [Mac] Firefox 4.0b12pre crash in mozilla::plugins::PPluginInstanceChild::FatalError [@ mozalloc_abort | NS_DebugBreak_P] opening a tab with Cmd-T while a Flash video has focus (youtube) → [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)
Whiteboard: [hardblocker][has patch] → [hardblocker]
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.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Verified Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
Crash Signature: [@ mozalloc_abort | NS_DebugBreak_P | mozilla::plugins::PPluginInstanceChild::FatalError ] [@ mozalloc_abort | NS_DebugBreak_P ]
You need to log in before you can comment on or make changes to this bug.