United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6647430 Java Kernel error message in development builds causing plugin crashes with Firefox
6647430 : Java Kernel error message in development builds causing plugin crashes with Firefox

Details
Type:
Bug
Submit Date:
2008-01-05
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-01-25
Component:
deploy
OS:
windows
Sub-Component:
deployment_toolkit
CPU:
generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10

Related Reports
Relates:
JDK-6647070 - JSObject reference counting problem

Sub Tasks

Description
When running the Java Plug-In out of a development build of the JRE, there is a "classes" directory but no lib/rt.jar. This causes the Java Kernel's preJVMStart() to report the following error upon launch of the first applet in the browser:

Java Error
Could not read file C:\Users\kbr\ws\6uN\j2se\build\WINDOW~1\lib\rt.jar.

The Windows MessageBox call which displays this dialog box runs a subordinate message pump on the current thread. In Firefox, this causes browser-related window messages to be processed out of order, leading to both the old and new Java Plug-In being called in an unexpectedly reentrant fashion. This is causing browser crashes in the new Java Plug-In which are described in the evaluation of 6647070. It is not possible to work around all of these issues because the reentrance to the plug-in's code causes some of the web page's initialization sequence to be performed out of order.

This is a potential problem with any of the error dialogs displayed during preJVMStart(). However, the one above is the most immediately problematic, as it prevents the Java Plug-In developers from effectively using development builds.

The best solution to the problem is as follows. In preJVMStart(), kernel.cpp, if we fail to open rt.jar, check for the existence of the "classes" directory in javaHome. If it is present, assume we're running in a development build and silently return without displaying the error dialog.

There might be other possible and more general solutions such as avoiding the use of the MessageBox API and writing a custom control and subordinate message pump for the error dialog, but this would be a lot of work and it is not even clear that it would solve the problem. It might be the case that even processing WM_PAINT messages in the subordinate message pump might be enough to cause Firefox to get back the flow of control. Note that using MB_TASKMODAL and other flags in the MessageBox call for the error dialog was tried with no success.

Comments
EVALUATION

Fixed by simply removing the error message.  It really isn't necessary, as an unreadable rt.jar will either be fine (as described here) or cause the JRE to generate its own error message a millisecond later.
2008-01-14 
SUGGESTED FIX

*** /tmp/geta3208	Fri Jan  4 16:25:03 2008
--- kernel.cpp	Fri Jan  4 16:23:33 2008
***************
*** 1384,1392 ****
                      // a write lock on it, hosing us.
                      file = CreateFile(rt, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL);
                      if (file == INVALID_HANDLE_VALUE) {
!                         ::LoadString(_Module.GetModuleInstance(), IDS_FILE_READ_ERROR, rawMsg, BUFFER_SIZE);
!                         wsprintf(msg, rawMsg, rt);
!                         error(msg);
                          ReleaseAndClose(startMutex);
                          return;
                      }
--- 1384,1402 ----
                      // a write lock on it, hosing us.
                      file = CreateFile(rt, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL);
                      if (file == INVALID_HANDLE_VALUE) {
!                         // See whether we're running out of a development build that
!                         // contains a classes directory but no rt.jar. If so, don't
!                         // display this error dialog.
!                         struct _stat stat;
!                         TCHAR classes[MAX_PATH];
!                         strcpy(classes, javaHome);
!                         strcat(classes, "classes");
!                         int result = _stat(classes, &stat);
!                         if (result != 0) {
!                             ::LoadString(_Module.GetModuleInstance(), IDS_FILE_READ_ERROR, rawMsg, BUFFER_SIZE);
!                             wsprintf(msg, rawMsg, rt);
!                             error(msg);
!                         }
                          ReleaseAndClose(startMutex);
                          return;
                      }
2008-01-05


Hardware and Software, Engineered to Work Together