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

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: 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

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

(My Flash version is 9.0 r115, BTW.)

Comment 2

[Samuel Sidler (old account; do not CC)]

I can't reproduce on 10.5 using Flash 9.0 r47. I'll upgrade and try again.

Comment 3

[Michelle Sintov]

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

Comment 4

[Mike Schroepfer]

-ing since it looks like a flash bug.  Michelle if this is a FF bug please do let us know...

Comment 5

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

Josh, do you think this might be our bug? If so, please renominate.

Comment 6

[Michelle Sintov]

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?

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

(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?

Comment 8

[Samuel Sidler (old account; do not CC)]

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.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 11

[Marcia Knous [:marcia]]

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.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 15

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

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.

Comment 16

[Michelle Sintov]

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?

Comment 18

[Marcia Knous [:marcia]]

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.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Michelle, you are right. The laatest Firefox 2 branch build doesn't crash with the testcase. I'll try to find the regression range.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As Josh mentioned in bug 400724 it could probably related to bug 420967.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

Attachment: gdb stack trace with debug symbols (crash from comment #22)

Comment 24

[Steven Michaud [:smichaud] (Retired)]

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())?

Comment 25

[Steven Michaud [:smichaud] (Retired)]

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

Comment 26

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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:[e-mail]-bugzilla409615-rev0/[e-mail]

Comment 27

[Marcia Knous [:marcia]]

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.

Comment 28

[Steven Michaud [:smichaud] (Retired)]

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 :-(

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 30

[Steven Michaud [:smichaud] (Retired)]

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

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: 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.

Comment 32

[Steven Michaud [:smichaud] (Retired)]

Theme problem?  I don't see that.

I think you're right -- it's not related.

Comment 33

[Samuel Sidler (old account; do not CC)]

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

Comment 34

[Steven Michaud [:smichaud] (Retired)]

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:[e-mail]-bugzilla419668-409615/[e-mail]

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Steven, your build works fine for me with the uploadsmart website. There is no crash when using one of these three upload methods.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

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

Comment 37

[Marcia Knous [:marcia]]

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.

Comment 38

[Steven Michaud [:smichaud] (Retired)]

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

You'll need to wait for tomorrow's equivalent.

Comment 39

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko Minefield/3.0b5pre ID:2008031723

Comment 40

[ChrisL]

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.

Comment 41

[Steven Michaud [:smichaud] (Retired)]

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