This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
A Jnlp distribution occasionally freeze during start-up after the "Done loading module" is displayed in the splash screen. There is a deadlock ( see attachment). This issue never happened with a Zip distribution. Application size is arround 60M and jars are signed. Reproduced using JWS 1.5 and 1.6.0_02.
Created attachment 63399 [details] Stack trace
Hm. Not sure how to solve. Class loading asks a SecurityManager for permission to continue, yet the SM is loaded by the CL being checked, and it is perhaps not fully resolved.
When the deadlock occur we can systematically see that 1 - in the "main" thread we try to load "org.openide.util.datatransfer.ExClipboard" due to the call to TopSecurityManager.makeSwingUseSpecialClipboard in class org.netbeans.NonGui finally the JNLPClassLoader try to load "java.awt.datatransfer.Clipboard" 2 - in the "AWT-EventQueue-2" we try to load "sun.text.resources.CollationData" and the TopSecurityManager try to check permission for "accessClassInPackage.sun.text.resources" Any idea of what changes in the app could have led to see this issue since it recently started to show up ?
Don't know of any recent changes that would have made this a regression.
Work around : comment call to TopSecurityManager.makeSwingUseSpecialClipboard in org.netbeans.core.NonGui(line 117) The hang does not appear any more but the functionality of ExClipboard is no longer available
The work around does not work, it just decrease the frequency of the freezes. The freeze can also be reproduced with netbeans-6.1-200805300101-ml : 1 - Create a new project using sample application FeadReader, copy the files master.jnlp and platform.properties attached into the project 2 - "Build JNLP" application 3 - Deploy the war file 4 - Install and run the application using Web Start The application will occasionally freeze ( thread dump in attached DeadlockTraceNB6.1.TXT)
Created attachment 64959 [details] Thread dump for NB 6.1 platform
Created attachment 64960 [details] file to use with FeedReader sample and NB6.1
Created attachment 64961 [details] master.jnlp to use with FeedReader sample and NB 6.1
Not sure I would be able to reproduce, but trying to fix based on what I see in the thread dumps. Seems like the loading of AWTPermission.class is the problem. Can preload this class, as was in fact already being done for several other classes (though to solve some long-lost deadlock during debugging, not JNLP). http://hg.netbeans.org/core-main/rev/de1508eb74a1 Since it seems you have already been testing source patches, it would be great if you could test this one. Mark VERIFIED if it works, else reopen and attach new thread dumps.
Explanation of what I _think_ was the problem (mainly based on the thread dump) and why the fix might work: SecurityManager's occupy a special place in class loading because they can be called while loading a class (SecurityManager.checkPackageAccess). ClassLoader's of course are involved in class loading too. The difference is that a ClassLoader impl itself is clearly loaded by a "lower" class loader, so there is a strict stratification. By contrast, the SM is set globally for the VM, so our TSM is called with cPA for every class that is loaded - even those classes in the same class loader as TSM itself, even classes in the boot classpath. This is arguably a design flaw in Java. What seems to have been happening here is that the first time TSM.cPA was called (in EQ), the test if (perm instanceof AWTPermission) was encountered, yet AWTPermission was not loaded yet - not a big surprise, probably there was no activity in AWT yet at all. So the class loader loading this code - JNLPClassLoader - asked to resolve and link in AWTPermission. Now JNLPClassLoader was already locking its parent AppClassLoader in a different thread (main), in the normal class loader delegation locking chain. (BTW this locking chain may be changed for JDK 7, mainly to support cyclic class loader graphs.) Unfortunately EQ was already holding locks in the wrong direction: AppClassLoader first (to load something from that loader), then JNLPClassLoader just because TSM's code triggered class loading. The fix ensures that AWTPermission is loaded as soon as TSM is initialized, so that the body of checkPermission (called from super's checkPackageAccess) does not mention any classes which would not already have been loaded. It seems that someone long ago did similar fixes for other unusual classes used from TSM, though apparently to solve some issue with running TSM in the debugger, rather than JNLP.
Verified, Thanks!!