JDK-8043229 : NPE in sun.lwawt.macosx.CEmbeddedFrame.getLayerPtr during applet startup
- Type: Bug
- Component: deploy
- Sub-Component: plugin
- Affected Version: 7-pool,8-pool,9
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: os_x
- Submitted: 2014-05-15
- Updated: 2014-10-17
- Resolved: 2014-05-29
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.
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 | JDK 9 |
|---|---|---|
7u76Fixed  |
8u20Fixed |
9 b22Fixed |
Related Reports
|
Blocks :
|
|
|
Relates :
|
Description
This exception is thrown when JVM relaunch happens due to 'unhealthy' current JVM which is in process of starting the applet. At this stage the EmbededFrame for this applet is already created: PluginMain.handleStartAppletMessage() invokes first AppletFrameCreator and then StartAppletRunner, the first one creates an EmbeddedFrame the second one starts the Applet execution. While the applet execution is being started the Applet2Manager.checkRunningJVMArgsSatisfying() finds out that the current JVM we are running in is 'unhealthy' for some reasons (too many Threads are started or too few memory left) and throws JreSelectException The exception is handled and processed in the Plugin2Manager.AppletExecutionRunnable.run(), which calls parentWindow.dispose(). This disposal of the Applet frame is a bit different than in a normal Applet lifecycle and it doesn't ignore such calls as setSize() in the future. The above means that this exception normally shouldn't affect the workflow of an applet because the Frame which generates exception is already disposed in favor of a new Applet Frame in another JVM. See more details in JDK-8021383 description.