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 246655 - OOME when executing an SQL query: GC overhead limit exceeded
Summary: OOME when executing an SQL query: GC overhead limit exceeded
Status: RESOLVED DUPLICATE of bug 248508
Alias: None
Product: db
Classification: Unclassified
Component: SQL Editor (show other bugs)
Version: 8.0
Hardware: All All
: P3 normal (vote)
Assignee: Libor Fischmeistr
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-23 06:41 UTC by paolosca
Modified: 2015-03-16 18:49 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: 211402

Attachments
stacktrace (1.32 KB, text/plain)
2014-08-23 06:41 UTC, paolosca 		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 paolosca 2014-08-23 06:41:11 UTC 
Build: NetBeans IDE 8.0 (Build 201403101706)
VM: Java HotSpot(TM) 64-Bit Server VM, 25.20-b23, Java(TM) SE Runtime Environment, 1.8.0_20-b26
OS: Linux

User Comments:
paolosca: I attempted to execute a postgresql query, a "cannot connect to server" window popped up along with several other greyed out windows and NetBeans became unresponsive.




Stacktrace: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   at java.util.Arrays.copyOf(Arrays.java:3332)
   at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137)
   at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121)
   at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:421)
   at java.lang.StringBuilder.append(StringBuilder.java:136)
   at java.lang.StackTraceElement.toString(StackTraceElement.java:172)
Comment 1 paolosca 2014-08-23 06:41:13 UTC 
Created attachment 148852 [details]
stacktrace
Comment 2 matthias42 2015-03-16 18:49:44 UTC 
Closing as duplicate of 248508. Short description: OOME without further information. Please recheck with a current nightly build, whether this is reproducible. If it is, please feel free to reopen.

This is interesting information:

- Which database (name + version) was the target for the select
- Home many rows are estimated in the resultset (based on the where clause, if any)
- What information (datatypes and estimated sizes) are part of the column-structure
- How many rows did you request in the "page size" dialog

Additionally the message.log and a threaddump + heapdump are helpful.

*** This bug has been marked as a duplicate of bug 248508 ***