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 240404 - OutOfMemoryError: Java heap space
Summary: OutOfMemoryError: Java heap space
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Theofanis Oikonomou
URL: https://netbeans.org/bugzilla/show_bu...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-13 10:37 UTC by marcosjunqueira
Modified: 2014-01-17 02:47 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 206507


Attachments
stacktrace (2.36 KB, text/plain)
2014-01-13 10:37 UTC, marcosjunqueira
Details

Note You need to log in before you can comment on or make changes to this bug.
Description marcosjunqueira 2014-01-13 10:37:00 UTC
Build: NetBeans IDE 7.4 (Build 201310111528)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b17
OS: Windows 7

User Comments:
marcosjunqueira: last boot message




Stacktrace: 
java.lang.OutOfMemoryError: Java heap space
   at java.util.Arrays.copyOfRange(Arrays.java:2694)
   at java.lang.String.<init>(String.java:203)
   at java.lang.StringBuffer.toString(StringBuffer.java:561)
   at org.jdom.input.TextBuffer.toString(TextBuffer.java:146)
   at org.jdom.input.SAXHandler.flushCharacters(SAXHandler.java:623)
   at org.jdom.input.SAXHandler.endElement(SAXHandler.java:678)
Comment 1 marcosjunqueira 2014-01-13 10:37:02 UTC
Created attachment 143889 [details]
stacktrace
Comment 2 Milos Kleint 2014-01-15 07:02:17 UTC
more or less a duplicate of issue 240445, not sure what we can do here. 137M sized text is pulled from the surefire report file via saxparser. No matter what parser we use (a pull kind comes to mind), we would eventually have to store that (and other) strings in the test results window anyway.

maybe just take some precautions and if the report file is huge, refuse to show it in test results window? or via pull parser manage to cut the output to manageable size?

Any idea Fanis? have you encountered this with ant projects?
Comment 3 Theofanis Oikonomou 2014-01-15 09:25:10 UTC
(In reply to Milos Kleint from comment #2)
> more or less a duplicate of issue 240445, not sure what we can do here. 137M
> sized text is pulled from the surefire report file via saxparser. No matter
> what parser we use (a pull kind comes to mind), we would eventually have to
> store that (and other) strings in the test results window anyway.
> 
> maybe just take some precautions and if the report file is huge, refuse to
> show it in test results window? or via pull parser manage to cut the output
> to manageable size?
> 
> Any idea Fanis? have you encountered this with ant projects?

AFAICR there was not a similar issue for ant. Anyway 100+MB test results report seems rare. A change in the parsing algorithm is out of scope for 8.0 I am afraid. At this point I can eliminate further processing of the results file if it bigger than say 50MB. Would that be acceptable?
Comment 4 Milos Kleint 2014-01-16 08:30:36 UTC
(In reply to Theofanis Oikonomou from comment #3)
> (In reply to Milos Kleint from comment #2)
> > 
> > Any idea Fanis? have you encountered this with ant projects?
> 
> AFAICR there was not a similar issue for ant. Anyway 100+MB test results
> report seems rare. A change in the parsing algorithm is out of scope for 8.0
> I am afraid. At this point I can eliminate further processing of the results
> file if it bigger than say 50MB. Would that be acceptable?

sounds reasonable, but doesn't prevent a OOME from multiple below 50M report files. 

a pull parsing solution would allow us to process such files but only include output/texts with a given maximum size. (well in the kilo area not mega)
Comment 5 Theofanis Oikonomou 2014-01-16 16:11:03 UTC
Changeset: a6e5ab8106bf
Author:    Theofanis Oikonomou <theofanis@netbeans.org>
Date:      2014-01-16 17:10
Message:
Comment 6 Theofanis Oikonomou 2014-01-16 16:18:04 UTC
(In reply to Milos Kleint from comment #4)
> (In reply to Theofanis Oikonomou from comment #3)
> > (In reply to Milos Kleint from comment #2)
> > > 
> > > Any idea Fanis? have you encountered this with ant projects?
> > 
> > AFAICR there was not a similar issue for ant. Anyway 100+MB test results
> > report seems rare. A change in the parsing algorithm is out of scope for 8.0
> > I am afraid. At this point I can eliminate further processing of the results
> > file if it bigger than say 50MB. Would that be acceptable?
> 
> sounds reasonable, but doesn't prevent a OOME from multiple below 50M report
> files. 
> 
> a pull parsing solution would allow us to process such files but only
> include output/texts with a given maximum size. (well in the kilo area not
> mega)

I agree but at least the fix minimises the risk of the OOME since AFAIK max heap size is set ~25% of available ram by default. I filed an enhancement to keep track of this and to be fixed in next release. Thank you
Comment 7 Quality Engineering 2014-01-17 02:47:52 UTC
Integrated into 'main-silver', will be available in build *201401170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/a6e5ab8106bf
User: Theofanis Oikonomou <theofanis@netbeans.org>
Log: Task #240404 - OutOfMemoryError: Java heap space