Bug 33040 - An exception appears after generating of javadoc for a method.
An exception appears after generating of javadoc for a method.
Status: RESOLVED DUPLICATE of bug 33165
Product: editor
Classification: Unclassified
Component: -- Other --
-S1S-
PC All
: P2 (vote)
: 3.x
Assigned To: issues@editor
issues@editor
: THREAD
: 31354 32810 33713 33822 33976 34065 34141 34904 35035 35543 35799 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-18 09:38 UTC by Marek Fukala
Modified: 2007-11-05 13:44 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The exception (3.37 KB, patch)
2003-04-18 09:39 UTC, Marek Fukala
Details | Diff
Exception stacktrace after #33214 was applied (1.18 KB, text/plain)
2003-05-14 13:16 UTC, Miloslav Metelka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Fukala 2003-04-18 09:38:20 UTC
[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.
Comment 1 Marek Fukala 2003-04-18 09:39:00 UTC
Created attachment 10015 [details]
The exception
Comment 2 Marek Fukala 2003-04-18 09:47:33 UTC
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.
Comment 3 ehucka 2003-04-18 10:02:41 UTC
I cannot reproduce it. It looks similar to #31354.
Have you set any breakpoints? 
Comment 4 Marek Fukala 2003-04-18 10:57:49 UTC
Yes, I have set some breakpoints and performed a debugging.
But then I removed them but the problem remained.
Comment 5 Martin Roskanin 2003-04-18 14:44:53 UTC
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

Comment 6 Jan Chalupa 2003-04-18 15:08:58 UTC
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.
Comment 7 Martin Roskanin 2003-04-18 16:12:08 UTC
OK Honza, you are right. I am continuing with investigation. It seems
it could be some synchronization problem on GapObjectArray's array.
Comment 8 Martin Roskanin 2003-04-18 17:34:28 UTC
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;
    }


Comment 9 Jan Chalupa 2003-04-18 18:05:04 UTC
To be more specific, javadoc is inserted at the caret position, not
above the method definition.
Comment 10 Miloslav Metelka 2003-04-22 12:35:24 UTC
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?
Comment 11 David Konecny 2003-04-22 12:52:46 UTC
It is hard to say something constructive about editor package. It is
threading is known to be buggy.
Comment 12 Jan Chalupa 2003-04-23 16:56:27 UTC
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.
Comment 13 Miloslav Metelka 2003-04-24 13:51:47 UTC
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.
Comment 14 Miloslav Metelka 2003-04-24 13:56:46 UTC
As we do not have a reproducible testcase I would like this bug to be
waived for Nevada.
Comment 15 Miloslav Metelka 2003-05-14 13:14:48 UTC
Thank to #33214 the stacktrace now looks like in the following attachment:
Comment 16 Miloslav Metelka 2003-05-14 13:16:23 UTC
Created attachment 10291 [details]
Exception stacktrace after #33214 was applied
Comment 17 Martin Roskanin 2003-05-19 09:06:47 UTC
*** Issue 33713 has been marked as a duplicate of this issue. ***
Comment 18 Miloslav Metelka 2003-05-23 11:20:15 UTC
*** Issue 33822 has been marked as a duplicate of this issue. ***
Comment 19 David Konecny 2003-06-02 13:02:58 UTC
*** Issue 34065 has been marked as a duplicate of this issue. ***
Comment 20 David Konecny 2003-06-02 13:05:15 UTC
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.
Comment 21 Martin Roskanin 2003-06-04 12:13:56 UTC
*** Issue 34141 has been marked as a duplicate of this issue. ***
Comment 22 Martin Roskanin 2003-06-16 09:23:52 UTC
*** Issue 31354 has been marked as a duplicate of this issue. ***
Comment 23 Martin Roskanin 2003-06-16 09:26:34 UTC
*** Issue 32810 has been marked as a duplicate of this issue. ***
Comment 24 Miloslav Metelka 2003-07-16 16:29:14 UTC
*** Issue 34904 has been marked as a duplicate of this issue. ***
Comment 25 Lukas Hasik 2003-07-17 16:58:22 UTC
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.
Comment 26 Martin Roskanin 2003-07-22 10:08:54 UTC
*** Issue 35035 has been marked as a duplicate of this issue. ***
Comment 27 Tomas Pavek 2003-07-25 16:45:04 UTC
*** Issue 33976 has been marked as a duplicate of this issue. ***
Comment 28 Martin Roskanin 2003-08-27 10:21:25 UTC
*** Issue 35543 has been marked as a duplicate of this issue. ***
Comment 29 Martin Roskanin 2003-08-27 13:38:42 UTC
*** Issue 35799 has been marked as a duplicate of this issue. ***
Comment 30 Miloslav Metelka 2003-09-05 16:27:45 UTC
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.
Comment 31 Antonin Nebuzelsky 2003-11-04 14:46:21 UTC
Fixed in Nevada Patch 1 and in Arrow.
Comment 32 _ gordonp 2003-11-06 17:48:07 UTC
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.
Comment 33 Miloslav Metelka 2003-11-07 15:07:13 UTC
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.
Comment 34 _ gordonp 2003-11-18 23:42:56 UTC
Has this fix been integrated into release35R yet?
Comment 35 Miloslav Metelka 2003-11-19 15:55:46 UTC
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.
Comment 36 Miloslav Metelka 2003-11-20 14:00:42 UTC
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 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo