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 230706 - OutOfMemoryError: GC overhead limit exceeded
Summary: OutOfMemoryError: GC overhead limit exceeded
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-04 07:13 UTC by stefan79
Modified: 2016-07-07 07:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 201149

Attachments
stacktrace (2.51 KB, text/plain)
2013-06-04 07:13 UTC, stefan79 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description stefan79 2013-06-04 07:13:43 UTC 
Build: NetBeans IDE Dev (Build nbms-and-javadoc-11072-on-20130604)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.21-b01, Java(TM) SE Runtime Environment, 1.7.0_21-b11
OS: Windows 7

User Comments:
stefan79: After Intial-Scann the OOE occured




Stacktrace: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   at java.util.Arrays.copyOfRange(Arrays.java:2694)
   at java.lang.String.<init>(String.java:203)
   at java.lang.String.substring(String.java:1913)
   at java.util.StringTokenizer.nextToken(StringTokenizer.java:352)
   at java.util.StringTokenizer.nextElement(StringTokenizer.java:407)
   at org.openide.util.Enumerations$FilEn.hasMoreElements(Enumerations.java:560)
Comment 1 stefan79 2013-06-04 07:13:44 UTC 
Created attachment 135301 [details]
stacktrace
Comment 2 stefan79 2013-06-04 09:55:19 UTC 
Heap-Dump was uploaded to Hudson: http://deadlock.netbeans.org/hudson/job/upload/244/
Comment 3 Ondrej Vrabec 2013-06-04 11:10:00 UTC 
error occurred while parsing a really long java file(s), the parser occupies most of the heap
Comment 4 Tomas Hurka 2013-07-17 10:50:35 UTC 
(In reply to comment #2)
> Heap-Dump was uploaded to Hudson:
> http://deadlock.netbeans.org/hudson/job/upload/244/
The heap dump is already part of exception report - there is no need to upload it separately to deadlock.netbeans.org
Comment 5 Svata Dedic 2013-09-16 10:17:34 UTC 
Sadly, the ER heapdump appears corrupted; the heapdump file uploaded to deadlock is gone. Sorry, cannot analyze.
Comment 6 Tomas Hurka 2013-09-16 10:21:46 UTC 
(In reply to Svata Dedic from comment #5)
> Sadly, the ER heapdump appears corrupted; 
Please, use 
gzip -dc heapdump-674776.hprof.gz > heapdump-674776.hprof
to extract the heap dump.
Comment 7 Svata Dedic 2013-09-16 14:13:55 UTC 
Tomas H.: thanks for the hint. gzip -dc works, the attachment is perhaps missing some checksum at the end;

According to the thread dump / local variables:
* Javac #1 is waiting in the queue as a deferred task from some parseWhenScanFinished(mime, task). Empty.
* Javac #2 is suspended in parkWhileSuspended, keeps ~2500 types entered (3149 compiled).
* Javac #3 is running in Editor Parsing Loop, 1698 types entered, ~290 input files. 

The total # of compilation units kept in memory corresponds to the two active instances of Javac. The suspended instance keeps 2500 + line number information. According to the profiler, the EndPosTableImpl in CompilationUnit retains really huge data, even in the suspended task. I suspect the profiler to report even tree sizes as part of retained size, but only the hashtable & integers from the larger files take ~200-500 KB for each of the file.
Comment 8 Exceptions Reporter 2015-08-02 16:48:19 UTC 
This bug already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=201149
Comment 9 Martin Balin 2016-07-07 07:17:46 UTC 
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss