Event based plugin shutdown causes crash when shutting zinc plugin

RESOLVED FIXED in mozilla1.9.1b1

Status

()

Core
Plug-ins
--
critical
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: Shane Blackett, Unassigned)

Tracking

({crash, regression})

Trunk
mozilla1.9.1b1
x86
Linux
crash, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041704 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041704 Minefield/3.0pre

I am one of the maintainers of our 3D rendering extension.
http://www.cmiss.org/cmiss/zinc
The event based shutdown of plugins
https://bugzilla.mozilla.org/show_bug.cgi?id=416953
which I can't see but which delays the shutdown
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/generic&command=DIFF_FRAMESET&file=nsObjectFrame.cpp&rev1=1.639&rev2=1.640&root=/cvsroot
 causes a crash as to cleanly
destroy our OpenGL objects we need to make current the OpenGL context
and destroy objects in it.  However the gtk objects wrapping the opengl
context have been destroyed already.  I have also tried registering for
an unrealize event on the appropriate gtk widgets but this also happens
too late.
I notice that two other plugins have had similar problems which have
been patched by specifically detecting these 
Bug 425157 and 
Bug 426524.
So if I misname my plugin "Flip4Mac" then my problem goes away.
I guess I'm requesting either a generic method for saying that
plugins require to be shutdown immediately (although given that the
triggering bug is "access denied" maybe there is some reason why this
isn't possible, although they could just follow the misnaming workaround)
or requesting that our small time but open source plugin
is added to the hard coded list. Currently "CMISS Zinc Plugin".


Reproducible: Always

Steps to Reproduce:
1. Install zinc plugin,
ftp://ftp.bioeng.auckland.ac.nz/cmiss/zinc/zinc-0.6.3.2-i686-linux-ff3.xpi
2. Upon restart you should get a one time only install page containing a
   3D torso object
3. Quit firefox
Actual Results:  
(firefox-bin:19505): GdkGLExt-WARNING **: glXMakeCurrent() failed
CmguiSceneViewer_gtk_unrealize_CB: Notifying CmguiCommandData
CmguiCommandData_closing_scene_viewer_notification: closing scene_viewer count 0
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadContextTag'.
  (Details: serial 42982 error_code 181 request_code 163 minor_code 11)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


Expected Results:  
Clean shutdown

Comment 1

10 years ago
please indicate which bug number you want to see, someone will either cc you to it or cc the relevant people from it here.
Severity: normal → critical
Component: Extension Compatibility → Plug-ins
Keywords: crash
Product: Firefox → Core
QA Contact: extension.compatibility → plugins
Version: unspecified → Trunk
(Reporter)

Comment 2

10 years ago
Bug 416953 is the listed in the change log as the original reason for the log,
so being able to see this may help to explain the reasons.

Comment 3

10 years ago
Shane, there is a nsPluginInstanceVariable_CallSetWindowAfterDestroyBool
that might be what you're looking for:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsObjectFrame.cpp&rev=1.651&root=/cvsroot&mark=1797#1778

That said, since it seems several plugins crash with the delayed Stop,
maybe we should reverse the logic and only delay those that we know
need it?
(Reporter)

Comment 4

10 years ago
I will try that variable, will have to wait till Monday sorry.
(Reporter)

Comment 5

10 years ago
Unfortunately the plugin NPAPI doesn't mention this flag
http://mxr.mozilla.org/mozilla/source/modules/plugin/base/public/npapi.h
and as far as I can see the plugin implementation hard codes that variable to false.
http://mxr.mozilla.org/mozilla/source/modules/plugin/base/src/ns4xPluginInstance.cpp#1383
So I don't think I can use it to work around the problem?
(Reporter)

Comment 6

10 years ago
The interim workaround we are using is to misname our plugin,
"Flip4Mac".

Updated

10 years ago
Blocks: 430219
(Reporter)

Updated

10 years ago
Keywords: regression

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
This was fixed (for 1.9.1) in bug 430219, but I'll see if we can reparent the plugin window to keep it alive for bug 485125 and all plugins on Linux.
No longer blocks: 430219
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Depends on: 430219
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Tested through layout/generic/test/test_plugin_clipping.xhtml and
http://hg.mozilla.org/mozilla-central/rev/f210fcece4f3
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.