JDK-7154248 : Nightly (Linux): Firefox fails to laod any applet using latest nightly build
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2012-03-15
  • Updated: 2013-06-20
  • Resolved: 2012-05-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u6Fixed 8 b31Fixed
Related Reports
Relates :  
JDK-7154661 - applets are crashing on linux (nightly build)
Relates :  
JDK-8016849 - Applets don't get loaded and the Firefox crashes under Mac OS X
Relates :  
JDK-7153446 - Redirect browser VM debug log to browser console
Description
Tested build: 8-b255-2012-03-15_207 (linux-i586)
Firefox tested: FF10.x/FF11

Firefox fails to load any applet using latest jdk8 nighlty build and crashes right away.
Sometimes it crashes as soon as it is invoked after creating a symlink inside "plugins" folder.  No such issue has been noticed with yest nightly build or promoted jdk8-b30

Steps to reporduce
1) Register firefox with above mentioned jdk8 nightly bundles
2) Invoke firefox, it could crash right away. If not then try to load any applet, it will surely crash
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/8/7154248.1
16-03-2012
EVALUATION I think crash is happening because of unpredictable order global static variables are initialized. in Log.cpp we use jpi_factory global variable to create mutex to init another static variable. When it crash jpi_factory is 0x0 (if my reading of disassembled code is correct). That explains why problem is only seen for some builds and ocassionally (init order is not defined). We should not be using global variables. Fix is to add static method to get access to the factory. This will enforce initialization order. Other problem with 7153446 is use of MozNPN_Invoke on non browser main thread. This is generally wrong but WebKit browsers seem to survive this just fine. However, Firefox loses lots of trace messages because of this. Right way is to use Async calls to delegate execution to the main thread. Unfortunatelly Async is not available for Safari (on Mac). So, need to make it conditional.
15-03-2012
EVALUATION I don't see this on my local Linux build neither.
15-03-2012
EVALUATION Confirmed regression caused by 7153446. Stack trace is: #0 0x023c28fe in global constructors keyed to Log.cpp () from /home/igor/tmp/jre1.8.0/lib/i386/libnpjp2.so #1 0x023c30fd in __do_global_ctors_aux () from /home/igor/tmp/jre1.8.0/lib/i386/libnpjp2.so #2 0x023b6c84 in _init () from /home/igor/tmp/jre1.8.0/lib/i386/libnpjp2.so #3 0x495bae40 in call_init.part.0 () from /lib/ld-linux.so.2 For unclear reason i do not see it in my own build ...
15-03-2012