Closed
Bug 104236
Opened 23 years ago
Closed 23 years ago
crash when flash context menu visible when page unloads
Categories
(Core Graveyard :: Plug-ins, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: tuukka.tolvanen, Assigned: peterl-bugs)
References
()
Details
(Keywords: crash, topembed, Whiteboard: [same problem in 4.x])
Attachments
(2 files, 2 obsolete files)
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
serhunt
:
review+
rpotts
:
superreview+
|
Details | Diff | Splinter Review |
Reproducible: Always
Steps to Reproduce:
1. http://www.tomshardware.com/
2. click on reload or a bookmark or link or whatever
3. get a context menu from one of the flash ads while the page is still visible
...crash when page disappears
MOZILLA caused an invalid page fault in
module <unknown> at 0000:0092b9c9.
Occurs on on Windows 98 with the following builds:
2001101103-0.9.5 TB36563438Q
2001101103-trunk TB36567688G
Comment 1•23 years ago
|
||
confirming with win2k build 20011011..
a useless stack from my debug:
06857d8c()
0012fc90()
06857341()
USER32! 77e030e0()
USER32! 77e05824()
nsAppShellService::Run(nsAppShellService * const 0x03940d10) line 457
main1(int 2, char * * 0x003577d0, nsISupports * 0x00000000) line 1291 + 32 bytes
main(int 2, char * * 0x003577d0) line 1619 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87d08()
Keywords: crash
Confirming on NT40. No stack trace is available with my debug build.
Comment 3•23 years ago
|
||
We probably need to do something like force the native context menus to rollup
when the plugin instance owner is being destroyed.
Maybe Chris or Rod can point out an example of how to do this?
Likely not our bug. This also happens with 4.x. Use Ctrl-R to reload the page
otherwise your mouse may be not fast enough to get back to the Flash ad before
the page disappears.
Comment 5•23 years ago
|
||
*** Bug 100538 has been marked as a duplicate of this bug. ***
can someone check if this is really a flash plugin issue or mozilla issue?
Comment 7•23 years ago
|
||
Andrei mentioned above that this is not a mozilla bug probably(happens in 4.x 2)
). Am marking invalid .
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 8•23 years ago
|
||
I don't think this is a Flash Player bug. I can get a similar crash with the
Quicktime plugin.
1. Go to www.apple.com
2. CTRL+R
3. Quickly right click on the Quicktime movie
4. Quickly select "About Quicktime Plug-in"
5. Crash!
QUICKTIME! 62b0a9f3()
QUICKTIMEWEBHELPER! 62c88ddb()
43003d00()
Hm... could be related to bug 116232.
Comment 10•23 years ago
|
||
*** Bug 123896 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
I am reopenning the bug. Attributing to third party is not sufficient here. Or
at minimum we need to know that flash is aware and is working on a fix.
Can we not handle this more gracefully?
Comment 12•23 years ago
|
||
Other notes at:
See bugscape:
http://bugscape.netscape.com/show_bug.cgi?id=12054
Comment 13•23 years ago
|
||
I'm trying to see if we can send the plugin a message to roll up the context
menu, but no luck so far.
BTW, this ALSO happens in 4.x.
Comment 14•23 years ago
|
||
Peter is this a Flash bug?
Shrirang is this reproducible in IE?
Comment 15•23 years ago
|
||
no, IE is fine.
Comment 16•23 years ago
|
||
I'm not 100% sure, but what I think is happening is ::TrackPopupMenu() is
called by the plugin and then we go around and destroy their window AND unload
their DLL from memory. It then looks like some invalid memory is being
referenced when we crash.
It tried to use ::SendMessage() at the time we destroy the plugin instance to
send a left button click OUTSIDE the window, but that didn't seem to help. The
attachment is a screenshot of Spy with this hack.
Comment 18•23 years ago
|
||
Nothing that I've tried works so far. I'm open to new ideas.
...waiting to hear back from Macromedia
Assignee: av → peterl
Status: REOPENED → NEW
Priority: -- → P3
Whiteboard: [same problem in 4.x]
Target Milestone: --- → mozilla1.0.1
Comment 19•23 years ago
|
||
I've done a little digging and here's what i've discovered. We encounter this
crash whenever Any 4.x PLUGIN enters a sub-event-loop during a page transition.
typically, this sub-event-loop is a context menu...
It turns out that the document is destroyed in response to a PLEvent (I believe
it is the proxied call to nsIStreamListener::OnStopRequest which originated on
the necko thread...).
If this PLEvent is processed by the plug-in's sub-event-loop, then we are in BIG
trouble... This is because part of the plugin destruction involves unloading
the plugin DLL. Unfortunately, codepages from the plugin DLL are currently
active because we are inside of the plugin's sub-event-loop :-(
Are you starting to see where this is going ;-) Document destruction proceeds
and the plugin DLL is unloaded, unfortunately when we return from processing the
PLEvent the code-pages containing the sub-event-loop are unloaded and we crash!
As far as i can see, the only way to protect against this situation is to defer
plugin unloading until we are at a 'safe, known base state' where we KNOW that
no plugin code is on the call stack !!
I'm not familiar enough with plugin unloading to really understand where this
'safe, known base state' is :-( However, a first attempt might be to trigger
plugin unloading off of a PLEvent... I *think* that by the time the PLEvent is
processed, the plugin will have been destroyed and none of its code pages should
be actively on the call stack.
In addition to this, i believe that on Win32 we need to call
::EnableWindow(pluginWnd, FALSE) as part of the plugin destruction process...
This causes any sub-event-loops caused by context menus, or dragging to be
exited. Refer to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/windows_92sl.asp
for more information...
It's interesting to note that on IE, this situation causes the page transition
to be deferred until the plugin leaves it sub-event-loop.
Comment 20•23 years ago
|
||
Rick, thanks for the analysis!
Here's a possible patch to unload the plugin library off a PLEvent. This alone
seems to prevent the crash.
Updated•23 years ago
|
Comment 22•23 years ago
|
||
This looks good to me.
Do you think it would make sense to wrap the call to PR_UnloadLibrary(...)
inside of:
NS_TRY_SAFE_CALL_VOID(PR_UnloadLibrary(mLibrary), nsnull));
this way, if the plugin GPFs during DLL unload, we don't crash...
i passed 'nsnull' as the 'aLibrary' argument because i figured that the plugin
had already been removed from the mPluginsList... So, we couldn't report the
name of the plugin... but we wouldn't crash either ;-)
-- rick
Comment 23•23 years ago
|
||
Yeah, I think using plugin saftey here would be nice. I also fixed another case
of PR_UnloadLibrary(). Please rsr=
Attachment #69279 -
Attachment is obsolete: true
Comment 24•23 years ago
|
||
Attachment #69369 -
Flags: superreview+
Comment 25•23 years ago
|
||
Lets push this to the trunk
Comment 26•23 years ago
|
||
Comment on attachment 69369 [details] [diff] [review]
updated patch
r=av
Attachment #69369 -
Flags: review+
Comment 27•23 years ago
|
||
patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: review
Resolution: --- → FIXED
Reporter | ||
Comment 28•23 years ago
|
||
Great! This appears to also fix a related problem on linux, where in the same
situation it would not crash, but the flash context menu would be left hanging
on top of all windows until Mozilla was closed. Now it goes away nicely. neat :)
Comment 29•23 years ago
|
||
requesting edt0.9.4+
Comment 30•23 years ago
|
||
not crashing anymore. I tried reloading ,clicking links ( and loading flash
context menu simultaneously). working fine on 0306 trunk. V
Status: RESOLVED → VERIFIED
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•