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.
[nevada #030415, jdk1.4.0_02] I created a java file, added a method and then performed 'Tools > Correct Javadoc'. The attached exception then appeared. Unfortunately this is not exactly reproducible.
Created attachment 10015 [details] The exception
After the first exception has been thrown the editor throws the exception during every compilation of any javafile. Rising the priority to P1. Emane, please check the problem up and modify the priority according to your opinion. Thanks.
I cannot reproduce it. It looks similar to #31354. Have you set any breakpoints?
Yes, I have set some breakpoints and performed a debugging. But then I removed them but the problem remained.
I cannot reproduce the problem, also. It seems that it can occur during some rare circumstances. That's why I am lowering the priority to standard value. If you can reproduce it often, please change the priority back with the exact steps of reproduction. Anyway, the problem of ArrayIndexOutOfBoundsException in GapObjectArray is already known, as Eman mentioned, in the bug #31354
Unfortunately, the "circumstances" don't seem to be so "rare" if the same stack-trace has been reported by three different users recently (#31354, #32641 and this one). I think it needs to be investigated and potentially fixed, because as Marek report indicates, when it happens, the exceptions keeps on coming up and the only way to get rid of them is to restart the IDE. Please investigate. -> P1.
OK Honza, you are right. I am continuing with investigation. It seems it could be some synchronization problem on GapObjectArray's array.
That's bad. It seems that document content is broken. Although I still didn't reproduced the origin problem, during the reproduction I reproduced something perhaps connected with this. Create two methods that returns some Object. Then after performing Tools/Correct Javadoc for the first method close the document. Choose "discard" on "save it?" dialog. Reopen the document and perform the Tools/Correct Javadoc for the second method. Javadoc is inserted at the wrong position: public Object ok(){ return /** * @return */ null; }
To be more specific, javadoc is inserted at the caret position, not above the method definition.
IMO we should think about revisiting of the thread model for document-related operations in org.openide.text. I've gone through the stacktrace and org.openide.text.DocumentLine$Set.getOriginal(DocumentLine.java:743) goes into LineListener.getLine() which calls LineStruct.originalToCurrent() that creates a Task class named Compute which delegates to originalToCurrentImpl(). The task is sent to RequestProcessor and the originating thread waits for its completion. Please correct me if I'm wrong but I don't see any obvious synchronization between the Compute task and a thread that possibly mutates the document during the time the Compute task executes or waits in the RP's queue. In ideal case all the document-related queries/modifications should go through the document's locking mechanism i.e. through using the javax.swing.text.Document.render() or our extensions in NbDocument.WriteLockable. IMHO to get rid of the issue we should try to make the things synchronous in org.openide.text.LineStruct by eliminating "PROCESSOR" variable completely. After the migration of BaseDocument to GapBranchElement was done the random line-related queries should all be fairly fast so there shouldn't be any performance degradation visible after making such change. Peter and David do you have any comments please?
It is hard to say something constructive about editor package. It is threading is known to be buggy.
QA has spent a significant amount of time trying to reproduce the problem, but neither of the known scenarios seems to work reliably. In fact, we weren't able to reproduce it at all. This is not to say the problem doesn't exist, but until a reproducible test case is found, we're fine with downgrading it to P2.
I've created http://www.netbeans.org/issues/show_bug.cgi?id=33214 to better diagnose whether the given line index is <0 or above the bounds of the line array.
As we do not have a reproducible testcase I would like this bug to be waived for Nevada.
Thank to #33214 the stacktrace now looks like in the following attachment:
Created attachment 10291 [details] Exception stacktrace after #33214 was applied
*** Issue 33713 has been marked as a duplicate of this issue. ***
*** Issue 33822 has been marked as a duplicate of this issue. ***
*** Issue 34065 has been marked as a duplicate of this issue. ***
I just closed issue 34065 as duplicate of this one. I'm not sure it was caused by this problem. But in the IDE.log attached in that issue you can find the same IndexOutOfBoundsException.
*** Issue 34141 has been marked as a duplicate of this issue. ***
*** Issue 31354 has been marked as a duplicate of this issue. ***
*** Issue 32810 has been marked as a duplicate of this issue. ***
*** Issue 34904 has been marked as a duplicate of this issue. ***
origin bug #31354 with RAINIER keyword was closed as duplicate of this one -> adding RAINIER keyword - otherwise it could be forgotten there is so many duplicate bugs and it looks that this is assigned to nobody... strange.
*** Issue 35035 has been marked as a duplicate of this issue. ***
*** Issue 33976 has been marked as a duplicate of this issue. ***
*** Issue 35543 has been marked as a duplicate of this issue. ***
*** Issue 35799 has been marked as a duplicate of this issue. ***
This bug should be fixed by the patch included as part of issue 33165. Right now we are in the process of testing of the patch.
Fixed in Nevada Patch 1 and in Arrow.
Please put this fix in Rainer (release35R branch) unless there are other reasons why it would be more difficult than copying a fix to a new branch.
Hi Gordon, I can put the fix there but consider that it includes both openide and editor and small fix in java module. All the affected files are in issue 33165 and there are also the three additional issues mentioned that occurred and were fixed after the main patch. I'll integrate into release35R at the begining of the next week.
Has this fix been integrated into release35R yet?
The integration is almost done - I expect I will commit tomorrow or even today. I apologize but I was delayed by by some unpredicted issues.
The complete patch for issue 33165 is now integrated into release35R branch. The diff and details are in #33165. I have tested it before integration and did not notice any apparent problems. It will now be tested thorughly by QA. Marking this issue as duplicate of issue 33165. *** This issue has been marked as a duplicate of 33165 ***