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.

Bug 45055 - IDE never finishes startup scan
Summary: IDE never finishes startup scan
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Tomas Hurka
URL:
Keywords: RANDOM
Depends on:
Blocks:
 
Reported: 2004-06-16 19:25 UTC by Jesse Glick
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
IDE log, incl. one thread dump; gzipped because it is really big (173.54 KB, application/octet-stream)
2004-06-16 19:27 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-06-16 19:25:51 UTC
040615. Not sure what is going on. I had started
an existing user dir (w/ caches etc.) using JDK
1.5.0 b55 for the first time (was using b54
before). That scanned the new src.zip as expected
and then was fine. I was however not getting
access to extra JDK sources that I had configured
(Sun-private impl sources) so I decided to shut
down and restart and see if that helped. This
second time I started, the scanning proceeded
quickly - already had the new src.zip parsed - but
when the scanning progress dialog hit the end, it
just stopped and did not go away. The last message
it shows is

Checking changes of:
org-netbeans-modules-apisupport-project.jar
Package: org.netbeans.spi.java.project.support.ui

which is suspicious since there is such a package
but not in that module.

Getting stack overflow errors etc.; will attach
complete log.
Comment 1 Jesse Glick 2004-06-16 19:27:31 UTC
Created attachment 15786 [details]
IDE log, incl. one thread dump; gzipped because it is really big
Comment 2 Jesse Glick 2004-06-16 19:32:38 UTC
After killing that IDE, I restart again. Now it stops progressing
immediately; progress bar never goes from the initial point.

After killing the IDE again, deleting mdrstorage cache, and
restarting, I get the scanning dialog blank for a while (30-60 sec I
think), with little apparent CPU or memory activity. Then it starts
showing scanning normally, and finishes startup apparently correctly.
Comment 3 Martin Matula 2004-06-19 15:00:07 UTC
The SOE is probably caused by the index inconsistency. For convenience
here is an excerpt of the stacktrace from the attached gz:

....
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.JavaClassImpl.getSuperClass(JavaClassImpl.java:191)
        at
org.netbeans.jmi.javamodel.JavaClass$Impl.getSuperClass(Unknown Source)
        at
org.netbeans.modules.javacore.parser.MDRParser.getSuperClass(MDRParser.java:1152)
        at
org.netbeans.modules.javacore.parser.Scope.constructMemberTypeScope(Scope.java:140)
        at
org.netbeans.modules.javacore.parser.Scope.createMemberTypeScope(Scope.java:128)
        at
org.netbeans.modules.javacore.parser.Scope.constructMemberTypeScope(Scope.java:145)
        at
org.netbeans.modules.javacore.parser.Scope.createMemberTypeScope(Scope.java:128)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:346)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:268)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:354)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:236)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:200)
        at
org.netbeans.modules.javacore.parser.MDRParser.processAST(MDRParser.java:177)
        at
org.netbeans.modules.javacore.parser.MDRParser.enterMembers(MDRParser.java:127)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.directUpdate(ResourceImpl.java:493)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.initResource(ResourceImpl.java:328)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.MetadataElement.initCheck(MetadataElement.java:122)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.SemiPersistentElement.getElementInfo(SemiPersistentElement.java:110)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.initChildren(ResourceImpl.java:249)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.ResourceImpl.initChildren(ResourceImpl.java:243)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.MetadataElement.initCheck(MetadataElement.java:128)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.SemiPersistentElement.getElementInfo(SemiPersistentElement.java:110)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.JavaClassImpl.initChildren(JavaClassImpl.java:454)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.JavaClassImpl.initChildren(JavaClassImpl.java:445)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.MetadataElement.initCheck(MetadataElement.java:128)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.SemiPersistentElement.getElementInfo(SemiPersistentElement.java:110)
        at
org.netbeans.modules.javacore.jmiimpl.javamodel.JavaClassImpl.getSuperClass(JavaClassImpl.java:191)
        at
org.netbeans.jmi.javamodel.JavaClass$Impl.getSuperClass(Unknown Source)
        at
org.netbeans.modules.javacore.parser.MDRParser.getSuperClass(MDRParser.java:1152)
r

Tomasi, please look at it. It would be nice if we could put in some
index inconsistency recovery code instead of calling
JavaClass.getSuperClass. But I am not sure if it is possible - does it
ever make sense to call JavaClass.getSuperClass from
MDRParser.getSuperClass? Shouldn't the superclass always be found in
superInfoMap? 
Comment 4 Tomas Hurka 2004-06-22 08:41:48 UTC
Moved to new subcomponent java/javacore.
Comment 5 Martin Matula 2004-06-24 22:33:37 UTC
The SOE was fixed by Tomas some time ago.
Comment 6 Quality Engineering 2007-09-20 11:55:50 UTC
Reorganization of java component