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.
Thread dump in attachment. Don't know how to reproduce, it happend just for the first time. However, I can not save my changes. NetBeans 3.3.1 RC3
Created attachment 4569 [details] The thread dump.
Reassigning to openide. It is very similar deadlock as in the issue #10826, but I am not sure whether it is duplicate. Please, reassign back if I am wrong.
If it is a duplicate then this is regression!
The #10826 is not a duplicate its different and that prob is solved. To this prob. From the thread dump it's posible to see there is a waiting for finish of task (in AWT) which was scheduled to internal UndoRedo RequestProcessor. But there is not possible detect which one is the UndoRedo RP. There are just 2 candidates, OpenIDE RP 1 or 3. But both are waiting for tasks. There is also a possibility the thread has finished, e.g the task has thrown Error instead of exception. I believe this was the case. In the rev 1.53 Jesse removed the catching errors of RP tasks, in editor module there are throwing of errors used in many places. Jessie I haven't find the thread dealing about, but some agreement needs to be taken. Either catch Throwable in RP or request strongly no task can throw Errors instead of Exceptions. or both. CC Jessie and editor, please tell something to this.
I'm sorry the Jessie's change came later then the prob occured so what I said above is not fully true.
Up to now I just named the UndoRedo internal RP. change: openide/../awt/UndoRedo.java [1.22] Will probably also add more robust check to RP in case of ErrorManager failure.
I still guess the RP thread finished somehow. I find just one another possibility it could happen. I.e. when was catched some exception from the task and then some another one thrown from ErrorManager in the exception handler. So I just added the more robust check to avoid this failure. possible fix: openide/../util/RequestProcessor.java [1.54] Additional: Jesse, please reconsidere if it wouldn't be better in RP to catch also Errors like before. It seems to me too error-prone unless we are sure no module do throw errors instead of exceptions, from possible tasks. Assigning to editor which can throw many errors in their code. Remove it sinve the errors are not handled now, and close the bug then.
Re. RequestProcessor.java 1.54: I think that rather than catching Exception here, ErrorManager.getDefault and NbErrorManager.notify should internally catch RuntimeException just to be as robust as possible. More generally than catching in RP. Re. catching Error in RP: I think catching Error is probably dangerous (OutOfMemoryError?!) but LinkageError may make sense. Mutex is essentially the same situation. Definitely if a module *does* throw a non-Exception from a task, this should be fixed in the module ASAP.
Also note that throwing of InternalError from a RP.java line 586 violates NB code conventions.
I agree (that using errors is wrong and robust ErrorManager). Will you take care about that? I mean fire bugs, tasks.
fixed in [maintrunk] /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.86; previous revision: 1.85 /cvs/editor/libsrc/org/netbeans/editor/EditorDebug.java,v <-- EditorDebug.java new revision: 1.19; previous revision: 1.18 /cvs/editor/libsrc/org/netbeans/editor/FindSupport.java,v <-- FindSupport.java new revision: 1.47; previous revision: 1.46 /cvs/editor/libsrc/org/netbeans/editor/SyntaxSeg.java,v <-- SyntaxSeg.java new revision: 1.22; previous revision: 1.21 /cvs/editor/libsrc/org/netbeans/editor/ext/FileStorage.java,v <-- FileStorage.java new revision: 1.21; previous revision: 1.20 /cvs/editor/libsrc/org/netbeans/editor/ext/java/JCFileProvider.java,v <-- JCFileProvider.java new revision: 1.21; previous revision: 1.20
Sure.
Should/could this be fixed in the next bugfix release and the Orion release of FFJ?
Yes, I am going to prepare the fix and the integration notice.
the fix is easy, just replacing Error with RuntimeException as shown on the diff for BaseDocument.java between 1.85 and 1.86. Other diffs of the modified files (see fix commit log above) are similar, so I didn't attach them. diff -r1.85 -r1.86 920c920 < throw new Error(WRITE_LOCK_MISSING); --- > throw new RuntimeException(WRITE_LOCK_MISSING);
integrated into [orion_fcs] /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.83.8.2.4.1; previous revision: 1.83.8.2 /cvs/editor/libsrc/org/netbeans/editor/EditorDebug.java,v <-- EditorDebug.java new revision: 1.17.28.1.4.1; previous revision: 1.17.28.1 /cvs/editor/libsrc/org/netbeans/editor/FindSupport.java,v <-- FindSupport.java new revision: 1.44.24.1; previous revision: 1.44 /cvs/editor/libsrc/org/netbeans/editor/SyntaxSeg.java,v <-- SyntaxSeg.java new revision: 1.21.36.1; previous revision: 1.21 /cvs/editor/libsrc/org/netbeans/editor/ext/FileStorage.java,v <-- FileStorage.java new revision: 1.19.24.1; previous revision: 1.19 /cvs/editor/libsrc/org/netbeans/editor/ext/java/JCFileProvider.java,v <-- JCFileProvider.java new revision: 1.18.22.1; previous revision: 1.18
Hi, as this is not reliably reproducible bug and I have not seen it for quite long time, I am marking it VERIFIED. Reopen if anybody disagrees.
Resolved for 3.3.x or earlier, no new info since then -> closing.