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.
Product Version: NetBeans IDE Dev (Build 080723) Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-119 System: Mac OS X version 10.5.3 running on i386; MacRoman; en_US (nb) I get assertion error while invoking JavaSource.runCompileControlTask(), see code snippet. Note: This is a regression from 6.5M1 JavaSource targetSource = JavaSource.forFileObject(getTargetFile()); String packageName = getPackageName(targetSource); public static String getPackageName(JavaSource source) { final String[] packageName = new String[1]; try { source.runUserActionTask(new AbstractTask<CompilationController>() { <<==== Assertion Error here public void run(CompilationController controller) throws IOException { controller.toPhase(JavaSource.Phase.ELEMENTS_RESOLVED); ExpressionTree packageTree = controller.getCompilationUnit().getPackageName(); if(packageTree != null) packageName[0] = packageTree.toString(); } }, true); } catch (IOException ex) { } return packageName[0]; }
Error: java.lang.AssertionError: JavaSource.runCompileControlTask called under Document write lock. at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:602) See issue 139301 for more detail on the Assertion error. Also note that I am not invoking document.write before JavaSource.runCompileControlTask call.
As the assertion says, you cannot call JavaSource.runCompileControlTask under the document write lock. The document is locked here (from the stack trace in issue 139301): org.netbeans.editor.BaseKit$PasteAction.actionPerformed(BaseKit.java:1689) I am afraid you will need to rewrite you code in such a way you will not invoke JS.rUAT under the document write lock. You are free to write-lock the document inside the JS.rUAT. The reason for this assertion is deadlock protection: consider two locks: the document lock and the Java lock. There is an infrastructure thread that runs various tasks. The tasks are executed under the Java lock and are free to take document read lock. If the callers of JS.rUAT would call it under the document write-lock, there would be two threads locking two lock in the opposite order, leading into deadlocks. The test was introduced into JavaSource class a very long time ago (most probably long before it was even merged into the trunk). The test is enabled only when assertions are enabled (which means the test is disabled during "release" builds), because it is considered to be relatively slow.
I tested the scenario with the setting -J-da in the netbeans.conf. Now I see a deadlock (attached) further while document.insertString(). I wonder how this worked before.
Created attachment 65570 [details] thread dump while IDE hang on DnD of Saas services