[10.4] Crash with flash file uploader [@ HIToolbox@0xf4c9b][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)]

VERIFIED FIXED in mozilla1.9beta5

Status

()

Core
Plug-ins
P2
critical
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: stephend, Assigned: smichaud)

Tracking

({crash, regression})

Trunk
mozilla1.9beta5
All
Mac OS X
crash, regression
Points:
---
Bug Flags:
blocking1.9 -
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(4 attachments)

(Reporter)

Description

10 years ago
Created attachment 294419 [details]
Crash stack

Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122204 Minefield/3.0b3pre

Summary: Crash [@ HIToolbox] on myspace photo uploader

http://crash-stats.mozilla.com/report/index/f7098766-b14f-11dc-9ff5-001a4bd43ef6?date=2007-12-23-12

Steps to Reproduce:

1. Log in to MySpace.com
2. Load http://viewmorepics.myspace.com/Modules/PhotoAlbums/Pages/Upload.aspx
3. Click "Browse"
4. Point to a file, and click OK

Expected Results:

Image file is accepted

Actual Results:

Firefox crashes
Flags: blocking1.9?
(Reporter)

Comment 1

10 years ago
(My Flash version is 9.0 r115, BTW.)
(Reporter)

Updated

10 years ago
Attachment #294419 - Attachment mime type: application/octet-stream → text/HTML
I can't reproduce on 10.5 using Flash 9.0 r47. I'll upgrade and try again.

Comment 3

10 years ago
Thanks for the bug report! The Flash Player team will investigate.

Comment 4

10 years ago
-ing since it looks like a flash bug.  Michelle if this is a FF bug please do let us know...
Flags: blocking1.9? → blocking1.9-
Josh, do you think this might be our bug? If so, please renominate.
Assignee: nobody → joshmoz

Comment 6

10 years ago
Thanks again for the bug report. We've tested this and we don't reproduce the bug Mac OS 10.4 running Firefox 2.0.0.11 and Flash Player 9.0.115.0. Do you reproduce this with Firefox 2.0?
(Reporter)

Comment 7

10 years ago
(In reply to comment #6)
> Thanks again for the bug report. We've tested this and we don't reproduce the
> bug Mac OS 10.4 running Firefox 2.0.0.11 and Flash Player 9.0.115.0. Do you
> reproduce this with Firefox 2.0?

I can only reproduce this bug (also exhibited on http://uploadsmart.com) with the trunk/Firefox 3 beta 1/2 builds; 2.0.0.x builds with Flash 9.0 r115 DO NOT crash.

Can we get someone from the Mac team looking at this, please?
Following the steps in comment 0 using Flash 9.0 r115 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008010804 Minefield/3.0b3pre I *CANNOT* reproduce this bug.

I assume in step 4, you mean "Select" instead of "OK". For me, the image I've chosen shows in the list of files to the left of the Browse button. I experience the same behavior using the uploadsmart.com multiple-file uploader.
Also crashes here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008011021 Minefield/3.0b3pre and Flash 9.0 r115.

The debugger doesn't show any bad data:

(gdb) frame 12
#12 0x3fd0d7ad in ns4xPluginInstance::HandleEvent (this=0x3fca9e80, event=0xbfffcaf0, handled=0xbfffcaf8) at /Users/henrik/Projects/mozilla/source/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:1267
1267	    result = CallNPP_HandleEventProc(fCallbacks->event,
(gdb) p fNPP
$1 = {
  pdata = 0x40c81000, 
  ndata = 0x3fca9e80
}
(gdb) p &fNPP
$2 = (NPP_t *) 0x3fca9e9c

Starting with frame 11 there is only disassembled code. Seems that it's an issue of r115 on Tiger only?
Summary: Crash [@ HIToolbox] on myspace photo uploader → Crash with flash file uploader [@ HIToolbox][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)]
(Reporter)

Comment 10

10 years ago
(In reply to comment #8)

<snip>
 
> I assume in step 4, you mean "Select" instead of "OK". For me, the image I've
> chosen shows in the list of files to the left of the Browse button. I
> experience the same behavior using the uploadsmart.com multiple-file uploader.

Yes, sorry; I meant to say "Select."  That's my Windows-centric view talking.
During testing of the Beta 3 candidate (Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3) I hit this stack twice while testing plugins. In both cases I was on this test case when it crashed: http://weblogs.mozillazine.org/marcia/archives/plugin-test.html.
Michelle, I got some more information. Could you please cross-check if this is a crash initiated by Flash? Its simple to reproduce with latest Firefox trunk build, Shockwave Flash 9.0 r115 installed and browsing for a file on http://uploadsmart.com/.

The top20 frames are:

#0  0x92edbc9b in GetDispatchRecHandle ()
#1  0x92f39b25 in TerminateDialogForTSMTE ()
#2  0x92f39975 in CloseDialog ()
#3  0x92f398db in DisposeDialog ()
#4  0x92d8499f in NavBaseDialog::~NavBaseDialog ()
#5  0x92d78a38 in NavDialogGetReply ()
#6  0x3cb7cdaa in dyld_stub_AEInstallEventHandler ()
#7  0x3c8a1a64 in dyld_stub_AEInstallEventHandler ()
#8  0x3c89f263 in dyld_stub_AEInstallEventHandler ()
#9  0x3ca4f55a in dyld_stub_AEInstallEventHandler ()
#10 0x3cbc15d9 in Flash_EnforceLocalSecurity ()
#11 0x3cbad78a in Flash_EnforceLocalSecurity ()
#12 0x2e2fc6c5 in ns4xPluginInstance::HandleEvent (this=0x3c377a50, event=0xbfffc900, handled=0xbfffc908) at /Users/henrik/Projects/mozilla/source/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:1271
#13 0x15e34058 in nsPluginInstanceOwner::ProcessEvent (this=0x3c378650, anEvent=@0xbfffcdfc) at /Users/henrik/Projects/mozilla/source/mozilla/layout/generic/nsObjectFrame.cpp:3249
#14 0x15e3362b in nsObjectFrame::HandleEvent (this=0x2616c10, aPresContext=0x3d026180, anEvent=0xbfffcdfc, anEventStatus=0xbfffca78) at /Users/henrik/Projects/mozilla/source/mozilla/layout/generic/nsObjectFrame.cpp:1366
#15 0x164a5571 in nsPresShellEventCB::HandleEvent (this=0xbfffcb08, aVisitor=@0xbfffca6c) at /Users/henrik/Projects/mozilla/source/mozilla/layout/base/nsPresShell.cpp:1220
(Reporter)

Comment 13

10 years ago
Re-requesting blocking, for the following reasons:

1) We're not yet sure if this is us or Flash (we should at least investigate if it's us, and if not, perhaps we could sprinkle some null checks or check our callers)
2) I'm using the latest version of Flash, and this is reproducible 100% for me on MySpace, which seems to be a pretty large portion of our demographic, if I'm not mistaken
Flags: blocking1.9?
The last stack frame in our code where I have access to the code is frame 12 (see my comment 12). I did a check for each variable in comment 9. We don't have any null value which could given over to CallNPP_HandleEventProc. This is a #define and calls parameter 1 which is a function pointer:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/plugin/base/public/npupp.h&rev=3.26&#155

(gdb) p fCallbacks->event
$1 = (NPP_HandleEventUPP) 0x353ba6ec < Flash_EnforceLocalSecurity+196>

Due to I don't have symbols for Flash I'm not able to fetch the values for Flash_EnforceLocalSecurity. But anyway the crash is inside Flash AFAICS.

A better testcase is http://uploadsmart.com/ where you don't have to register.
Lets give this a shot. If there is a way we can fix or work around this in our code we should give it a try.

However there is a risk that there is nothing we can do on our end and that this really needs to be fixed in the flash code.

Michelle: Any help we could get from the flash team would be really appreciated. Firefox 3 is getting released soon and it would be sad to be shipping with this crasher so getting this looked into before would rock.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2

Comment 16

10 years ago
The Flash Player calls NavDialogGetUserAction once, and after that, the Flash Player calls NavDialogGetReply. While the Flash Player code is designed to only call NavDialogGetReply one time for the navigation dialog box, for some reason it appears that the Flash Player is actually calling NavDialogGetReply two times, and I think it's this second time that is crashing. The stack listed in comment #12 is the same as I see from the Flash Player, in that the Flash Player is calling NavDialogGetReply(), and from there to the crashing point the stack is what I see.

In Firefox 2, the Flash Player does not call NavDialogGetReply twice, only once.

Since this didn't happen in Firefox 2, would it be possible to determine where the regression occurred in Firefox 3?
Duplicate of this bug: 400724
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4 and r115, I crash 100% of the time when uploading a jpg file using the uploadsmart demo. I do not see a crash using Leopard using the same build.
Keywords: qawanted
Summary: Crash with flash file uploader [@ HIToolbox][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)] → [10.4] Crash with flash file uploader [@ HIToolbox][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)]
Whiteboard: [needs-regression-range]
Michelle, you are right. The laatest Firefox 2 branch build doesn't crash with the testcase. I'll try to find the regression range.
It's interesting. Going back to June last year shows me that the button doesn't react on mouse clicks. This happens between the builds 070201 and 070603. Luckily I'm still able to use the keyboard to open the dialog. But all of these builds are crashing. The real regression range is between the following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070326 Minefield/3.0a4pre ID:2007032604

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070327 Minefield/3.0a4pre ID:2007032704

Checked in patches within this timeframe:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-26+03%3A00%3A00&maxdate=2007-03-27+05%3A00%3A00&cvsroot=%2Fcvsroot

Josh, could bug 344427 be the cause of this crash?
Keywords: qawanted → regression
Hardware: PC → All
Whiteboard: [needs-regression-range]
As Josh mentioned in bug 400724 it could probably related to bug 420967.
(Assignee)

Comment 22

10 years ago
Here's another, very easy way to reproduce this problem (with today's trunk
nightlies).  For some reason I can only get it to happen on OS X 10.4.11 (not
on 10.5.2).  But on 10.4.11 it's 100% effective:

1) Visit http://www.element-it.com/Examples/MultiPowUpload/SimpleUpload.html
   and click on the Browse button -- an OS-level file picker will open up.

2) In the file picker, choose one file and click the Select button -- you'll
   crash.
(Assignee)

Comment 23

10 years ago
Created attachment 308682 [details]
gdb stack trace with debug symbols (crash from comment #22)
(Assignee)

Comment 24

10 years ago
Michelle, looking at my stack trace from comment #23, I notice
something odd:

1) NavGetFileDialog::~NavGetFileDialog() is called once (possibly as
   the result of a call to NavDialogGetReply()) on an idle event (sent
   via nsPluginInstanceOwner::Notify() to the Flash plugin).

2) NavGetFileDialog::~NavGetFileDialog() is called again, on the same
   stack (this time definitely as the result of a call to
   NavGetFileDialog::~NavGetFileDialog()) on a focus event (the
   browser window is being focused again after the file picker window
   was closed).

Yes, those two events should probably not be sent on the same stack
(and if they weren't the crash probably wouldn't happen).  But I
suspect there's not much we can do to stop it.

So the question becomes:  Shouldn't the Flash plugin know that, as of
the first call to NavGetFileDialog::~NavGetFileDialog(), the file
picker window has already been closed?  And shouldn't this prevent the
second call to NavDialogGetReply() (and to
NavGetFileDialog::~NavGetFileDialog())?
(Assignee)

Comment 25

10 years ago
> But I suspect there's not much we can do to stop it.

Well, I probably _could_ come up with some kind of hack.

But I'd still like to hear your response to my question.
(Assignee)

Updated

10 years ago
Assignee: joshmoz → smichaud
(Assignee)

Comment 26

10 years ago
Created attachment 308902 [details] [diff] [review]
Provisional fix.

> Well, I probably _could_ come up with some kind of hack.

Well, here it is :-)

I discovered that, for QuickDraw plugins,
nsChildView::StartDrawPlugin() simply discards all reentrant plugin
events (or rather, it causes them to be discarded).  But it doesn't do
this for CoreGraphics plugins.

Changing the code to discard reentrant plugin events for both kinds of
plugins resolves this bug.

The equivalent code on the 1.8 branch (nsWindow::StartDrawPlugin())
only supports QuickDraw plugins, but doesn't discard reentrant plugin
events.  But I suspect the problem didn't arise until the new thread
manager was landed on the trunk a year or two ago.  If so, this
explains why this crash doesn't happen on the 1.8 branch.

In principle (I think), plugins should be able to deal with reentrant
calls to nsIPluginInstance::HandleEvent().  But I suspect that they
haven't had to do put up with this behavior, on any platform, before
the change to the new thread manager (on trunk).  So it's
understandable that plugin vendors might think this is really a
Mozilla.org problem.

In any case, we're close to Firefox 3's release, and need a quick fix.
I hope this is it.

The one worry I have is that allowing reentrant plugin events might
actually have fixed some problems.  So if we now disallow them, these
problems might reappear.  But I think the risk of this is small, and
that we should go ahead with my current fix.

It helps that we still have one more beta (beta5) to test this in.

Here's a tryserver build made with this patch:

https://build.mozilla.org/tryserver-builds/2008-03-12_09:24-smichaud@mozilla.com-bugzilla409615-rev0/smichaud@mozilla.com-bugzilla409615-rev0-firefox-try-mac.dmg
Attachment #308902 - Flags: review?(joshmoz)
No crash for me using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008031209 Minefield/3.0b5pre, which is the tryserver build in Comment 26. I used the site in Comment 22 to test - I believe before it was crashing regularly. I also tested uploadsmart and no crash there either using the build. Next up is Leopard.
(Assignee)

Comment 28

10 years ago
Unfortunately, this patch doesn't fix the crashes (in Leopard)
reported at bug 419668 (I still see the same crash I reported in
bug 419668 comment #21).

So I guess we'll have to deal with that bug separately :-(
Steven, I can also no longer reproduce the crash. Works fine. But one thing which is still suspicious. Why has the OK button on http://uploadsmart.com/demo.php no label on it?
(Assignee)

Comment 30

10 years ago
> Why has the OK button on http://uploadsmart.com/demo.php no label on
> it?

I don't see an "OK button" ... and I'm using Firefox 2.0.0.12 on Linux
:-)

Tell me exactly what you're referring to.
Created attachment 308952 [details]
Missing label of Ok/Open button

Sorry, I meant the OK/Open button within the file dialog. But I don't think that it is related to this bug.
(Assignee)

Comment 32

10 years ago
Theme problem?  I don't see that.

I think you're right -- it's not related.
This crash is currently #51 overall and #12 on Mac.

http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b4&range_value=2&signature=HIToolbox%400xf4c9b
Summary: [10.4] Crash with flash file uploader [@ HIToolbox][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)] → [10.4] Crash with flash file uploader [@ HIToolbox@0xf4c9b][@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)]

Updated

10 years ago
Attachment #308902 - Flags: superreview?(roc)
Attachment #308902 - Flags: review?(joshmoz)
Attachment #308902 - Flags: review+
(Assignee)

Comment 34

10 years ago
Here's a tryserver build made with the latest patches for this bug
(bug 409615) and bug 419668.  This should make testing easier.

https://build.mozilla.org/tryserver-builds/2008-03-14_10:55-smichaud@mozilla.com-bugzilla419668-409615/smichaud@mozilla.com-bugzilla419668-409615-firefox-try-mac.dmg
Steven, your build works fine for me with the uploadsmart website. There is no crash when using one of these three upload methods.
Attachment #308902 - Flags: superreview?(roc) → superreview+
(Assignee)

Comment 36

10 years ago
Landed on trunk:

Checking in widget/src/cocoa/nsChildView.mm;
/cvsroot/mozilla/widget/src/cocoa/nsChildView.mm,v  <--  nsChildView.mm
new revision: 1.321; previous revision: 1.320
done
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Steven: Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008031704 Minefield/3.0b5pre, I don't crash, but unfortunately this crashes for every time using the equivalent Tiger nightly.
(Assignee)

Comment 38

10 years ago
Marcia, that nightly doesn't contain the patch for this bug.

You'll need to wait for tomorrow's equivalent.
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko Minefield/3.0b5pre ID:2008031723
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9beta5

Comment 40

10 years ago
I have the same the exact same problem.
Firefox has crashed 4 times in the last 24 hours.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Creative ZENcast v1.00.19

Windows XP SP3

Flash version: 9,0,124,0

Using this Flash Uploader:
  http://www.element-it.com/DemoMultiPOW.aspx
  DEMO:
  http://www.element-it.com/Examples/MultiPowUpload/SimpleUpload.html


Event log:

Faulting application firefox.exe, version 1.9.0.3071, faulting module unknown, version 0.0.0.0, fault address 0x00000000.

Faulting application firefox.exe, version 1.8.20080.40413, faulting module unknown, version 0.0.0.0, fault address 0x00010103.

(Assignee)

Comment 41

10 years ago
(In reply to comment #40)

The problem reported here was OS-X-only, and has been fixed.  So you
have a different problem.

Please open a new bug.

When you do, please specify the Breakpad IDs for your crashes.  You
should be able to find them by running Firefox and entering
"about:crashes" in the location bar.
Crash Signature: [@ HIToolbox@0xf4c9b] [@ ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)]
You need to log in before you can comment on or make changes to this bug.