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 36011 - IDE crashed with OutOfMemoryError
Summary: IDE crashed with OutOfMemoryError
Status: VERIFIED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcsgeneric (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P1 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2003-09-10 14:17 UTC by Jan Becicka
Modified: 2003-12-11 14:27 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Full Thread Dump (14.22 KB, text/plain)
2003-09-10 14:17 UTC, Jan Becicka
Details
java.lang.IllegalStateException at org.netbeans.api.projects.ProjectMemberList.itemToMember(ProjectMemberList.java:400) (1.20 KB, text/plain)
2003-09-10 14:19 UTC, Jan Becicka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Becicka 2003-09-10 14:17:12 UTC
Build 200309100000, Windows XP, JDK 1.4.2

I invoked New Wizard - Basic Java Application and
I tried to change home directory. I left "Select
Home Directory" dialog opened for a while and IDE
crashed with OutOfMemoryError.
Comment 1 Jan Becicka 2003-09-10 14:17:51 UTC
Created attachment 11572 [details]
Full Thread Dump
Comment 2 Jan Becicka 2003-09-10 14:19:41 UTC
Created attachment 11573 [details]
java.lang.IllegalStateException at org.netbeans.api.projects.ProjectMemberList.itemToMember(ProjectMemberList.java:400)
Comment 3 Milan Kubec 2003-09-10 14:25:09 UTC
OutOfMemoryError happened to me as well with the same build, but I
haven't any useful data from it. I was working with the IDE about an
hour and something.
Comment 4 Jan Becicka 2003-09-10 14:41:46 UTC
Memory consumption of project build is too high. I created project and
I used openide sources as java source roots. Memory meter in NetBeans
shows, that ~80MB is used. It is too much IMHO.
Comment 5 Jan Becicka 2003-09-10 16:06:38 UTC
I started IDE with fresh userdir and NetBeans memory meter shows that
80MB is used. Windows Task Manager shows that runide uses ~125MB. Only
Sample Project is opened.
Comment 6 Jesse Glick 2003-09-10 18:19:47 UTC
Cf. issue #35974.
Comment 7 Vitezslav Stejskal 2003-09-12 11:44:49 UTC
IMO opening 'Select home directory' dialog has nothing to do with this
error. The only active parts of IDE was the EQ and code completion
update. I think the problem is either in the infrastrutcture
(ProjectMembers) or in masterfs or in the java code completion. Could
you try to verify that OOME is really exposed when using code
completion? (e.g. try to work with the IDE without opening any java
file in the editor vs. create the project with lots of
sources/resources, open some java source and try to invoke the code
completion and do nothing more, the IDE should start building cc
database - check the CPU and disk activity) Thanks.
Comment 8 Jan Becicka 2003-09-12 12:34:20 UTC
As I mentioned before. Root of the problem is, that memory consumption
is enormous. If you just start IDE and do nothing more, you have
almost whole heap consumed no matter what next action you do.
OutOfMemoryError has nothing to do with "open" dialog nor ant module
(issue #35974) nor Code Completion IMHO.
Comment 9 Tomas Zezula 2003-09-25 09:06:45 UTC
I've spent some time with memory usage analyses.
And I've found very interesting results.
The number of Projects, ProjectMembers, JavaMembers and LookNodes is
quite reasonable and proportional to the number of artefacts in the
project.
I had 2 simple projects and all the Project, Java and Looks stuff has
instance count less than 100 per class.
But the heap size was very large even after the IDE start, 77,710,864B
while the heap size is 96MB. This does not give too much space for IDE
to run. It is quite obvious that parsing of the code completion
database while doing another memory demanding operation crashes the IDE.
I've taken a closer look to the initial memory usage and I've found
following results:
There was more than 250,000 instances of the HashMap.Entry,
more than 23,000 vsc UserCommands
and so on.
I've disabled the VCS modules and the initial heap size decreases
from 77MB+ to 11MB.
For example the instance count of the HasMap.Entry descreases 10 times.
Comment 10 Vitezslav Stejskal 2003-09-25 12:16:41 UTC
VCS guys could you please look at this? It might be related to
MasterFilesystem also (just a guess).
Comment 11 Martin Entlicher 2003-09-25 12:33:46 UTC
> I've disabled the VCS modules and the initial heap size decreases
> from 77MB+ to 11MB.
> For example the instance count of the HasMap.Entry descreases 10
> times.

Huh, this looks like a very serious problem in VCS. It looks almost
unbelivable. It's true, that all VCS profiles need to be parsed at the
startup now, but 23,000 instances of UserCommands is certaily a bug.

I'll look at the problem. I doubt it has anything with the MasterFS
although MasterFS initiates the VCS activity.
Comment 12 Martin Entlicher 2003-09-30 10:58:01 UTC
I can confirm what Tomas reported.
There are:
36041 instances of Condition class,
23614 instances of UserCommandSupport,
23607 instances of UserCommand.

The big number of HashMap.Entry objects and IdentityHashMap is a
consequence of this.

The problem seems to be in UserCommandConditions class. Method
addPropertyToCommand() splits the command with every new conditioned
property. This leads to exponential growth of the number of commands
with the number of conditions. This needs to be redesigned.

Moving to vcsgeneric module.

Comment 13 Martin Entlicher 2003-10-02 09:30:41 UTC
Fixed in the prj40_prototype branch.

According to my analysis after the first start, the memory usage
dropped to ~12MB.

There were:
18 612 instances of HashMap$Entry
   168 instances of Condition
   120 instances of Condition$Var
   172 instances of UserCommand
   174 instances of UserCommandSupport
   177 instances of CommandsTree

These numbers are much more reasonable, thus I consider this problem
as fixed.

Checking in commands/ConditionedCommands.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Attic/ConditionedCommands.java,v 
<--  ConditionedCommands.java
new revision: 1.1.2.3; previous revision: 1.1.2.2
done
Checking in commands/UserCommandIO.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/UserCommandIO.java,v 
<--  UserCommandIO.java
new revision: 1.14.4.4; previous revision: 1.14.4.3
done
RCS file:
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Attic/ConditionedCommandsBuilder.java,v
done
Checking in commands/ConditionedCommandsBuilder.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Attic/ConditionedCommandsBuilder.java,v 
<--  ConditionedCommandsBuilder.java
new revision: 1.1.2.1; previous revision: 1.1
done
Removing commands/UserCommandConditions.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/commands/Attic/UserCommandConditions.java,v 
<--  UserCommandConditions.java
new revision: delete; previous revision: 1.1.2.3
done
Processing log script arguments...
More commits to come...
Checking in globalcommands/GlobalExecutionContext.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/globalcommands/Attic/GlobalExecutionContext.java,v 
<--  GlobalExecutionContext.java
new revision: 1.1.2.9; previous revision: 1.1.2.8
done
Processing log script arguments...
More commits to come...
Checking in projectsettings/CommandLineVcsFileSystemInstance.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/projectsettings/CommandLineVcsFileSystemInstance.java,v 
<--  CommandLineVcsFileSystemInstance.java
new revision: 1.22.4.4; previous revision: 1.22.4.3
done
Processing log script arguments...
More commits to come...
Checking in recognizer/CommandLineFSRecognizer.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/recognizer/CommandLineFSRecognizer.java,v 
<--  CommandLineFSRecognizer.java
new revision: 1.2.4.8; previous revision: 1.2.4.7
done


Checking in CommandLineVcsFileSystem.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/CommandLineVcsFileSystem.java,v 
<--  CommandLineVcsFileSystem.java
new revision: 1.128.4.11; previous revision: 1.128.4.10
done
Checking in Profile.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/Attic/Profile.java,v 
<--  Profile.java
new revision: 1.1.2.5; previous revision: 1.1.2.4
done
Checking in ProfilesFactory.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/Attic/ProfilesFactory.java,v 
<--  ProfilesFactory.java
new revision: 1.1.2.9; previous revision: 1.1.2.8
done
Checking in UserCommandsEditor.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/UserCommandsEditor.java,v 
<--  UserCommandsEditor.java
new revision: 1.17.4.3; previous revision: 1.17.4.2
done
Checking in UserCommandsPanel.java;
/cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/UserCommandsPanel.java,v 
<--  UserCommandsPanel.java
new revision: 1.29.4.5; previous revision: 1.29.4.4
done
Comment 14 Martin Entlicher 2003-10-02 09:56:32 UTC
Also the tests were modified to reflect the fix and a new test was
added.
The tests were passed, so I hope that I didn't introduce any
regressions.

Checking in UserCommandIOTest.java;
/cvs/vcsgeneric/test/unit/src/org/netbeans/modules/vcs/advanced/commands/Attic/UserCommandIOTest.java,v 
<--  UserCommandIOTest.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Checking in commandsTestIn.xml;
/cvs/vcsgeneric/test/unit/src/org/netbeans/modules/vcs/advanced/commands/Attic/commandsTestIn.xml,v 
<--  commandsTestIn.xml
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
RCS file:
/cvs/vcsgeneric/test/unit/src/org/netbeans/modules/vcs/advanced/commands/Attic/ConditionedCommandsBuilderTest.java,v
done
Checking in ConditionedCommandsBuilderTest.java;
/cvs/vcsgeneric/test/unit/src/org/netbeans/modules/vcs/advanced/commands/Attic/ConditionedCommandsBuilderTest.java,v 
<--  ConditionedCommandsBuilderTest.java
new revision: 1.1.2.1; previous revision: 1.1
done
Comment 15 Jan Becicka 2003-10-06 13:43:48 UTC
Verified in 200310060000