Home » Language IDEs » Java Development Tools (JDT) » eclipse 3.2.1 running OutOfMemory while building workspace
| eclipse 3.2.1 running OutOfMemory while building workspace [message #250794] |
Tue, 22 January 2008 11:17  |
Eclipse User |
|
|
|
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all. You
can work with eclipse for a week without any problems and on the next day it
runs out of memory every half an hour. The problem only occurs while
building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum heap
size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more and
more memory while building the workspace without releasing any memory that
is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we are
using?
Any help welcome...
Best,
Dirk
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250801 is a reply to message #250794] |
Tue, 22 January 2008 12:17  |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Dirk Wenke wrote:
> Hi,
>
> I currently have a problem with my eclipse running OutOfMemory while
> building the workspace.
> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
> JDK1.5.
> In the workspace we have something about 60 additionally plugins we are
> developing.
>
> This is a really strange problem, because it is not reproducible at all. You
> can work with eclipse for a week without any problems and on the next day it
> runs out of memory every half an hour. The problem only occurs while
> building the workspace.
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum heap
> size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more and
> more memory while building the workspace without releasing any memory that
> is no longer needed.
>
> I already tried it with a completely new eclipse installation and a new
> workspace, but the problem still occurs.
>
> Is this a known problem? Or may this be caused by an external library we are
> using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250837 is a reply to message #250801] |
Wed, 23 January 2008 03:51 |
| Eclipse User |
|
|
|
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem. We
already tried to solve the problem by setting the maxPermSize, but that did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
news:fn58dv$661$3@build.eclipse.org...
> Dirk Wenke wrote:
>> Hi,
>>
>> I currently have a problem with my eclipse running OutOfMemory while
>> building the workspace.
>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>> JDK1.5.
>> In the workspace we have something about 60 additionally plugins we are
>> developing.
>>
>> This is a really strange problem, because it is not reproducible at all.
>> You can work with eclipse for a week without any problems and on the next
>> day it runs out of memory every half an hour. The problem only occurs
>> while building the workspace.
>>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>> I already tried it with a completely new eclipse installation and a new
>> workspace, but the problem still occurs.
>>
>> Is this a known problem? Or may this be caused by an external library we
>> are using?
>
> Look carefully at the .log messages when this happens - I'll bet it is
> actually a PermGen space error, not a heap space problem.
> If so, you'll need to set the max PermGen size in your eclipse.ini -
> Google for how to do that, it is a much-discussed topic (the default
> PermGen size on Sun JVMs is, unfortunately, very small).
>
> Hope this helps,
> Eric
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250842 is a reply to message #250837] |
Wed, 23 January 2008 04:07 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070200020805050403080203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in
my workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
never run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might
have an editor that's leaking than that the build itself is leaking the
memory. The problem with memory exhaustion is that one tends to blame
the straw that broke the camel's back because it's the most obvious, but
it might not be the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
> Hi Eric,
>
> thanks for your help. But it does not look like a PermGen space problem. We
> already tried to solve the problem by setting the maxPermSize, but that did
> not work.
> The exception logged to the eclipse .log looks like the following:
>
> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
> !MESSAGE Java heap space
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
> at
> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
> !SESSION 2007-12-04
> 09:28:52.562 -----------------------------------------------
> eclipse.buildId=M20060921-0945
> java.version=1.5.0_10
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Framework arguments: -Xmx512M
> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>
>
> Any other comments welcome :)
>
> Best,
>
> Dirk
>
>
>
> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
> news:fn58dv$661$3@build.eclipse.org...
>
>> Dirk Wenke wrote:
>>
>>> Hi,
>>>
>>> I currently have a problem with my eclipse running OutOfMemory while
>>> building the workspace.
>>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>>> JDK1.5.
>>> In the workspace we have something about 60 additionally plugins we are
>>> developing.
>>>
>>> This is a really strange problem, because it is not reproducible at all.
>>> You can work with eclipse for a week without any problems and on the next
>>> day it runs out of memory every half an hour. The problem only occurs
>>> while building the workspace.
>>>
>>> It seems like there exists some kind of memory leak. Initially we ran
>>> eclipse with -Xmx256m and after these problems we increased the maximum
>>> heap size up to 1GB, but eclipse is still running out of memory. In the
>>> preferences we enabled the display of the heap status: Normally eclipse
>>> occupies something between 100MB to 150MB but sometimes it occupies more
>>> and more memory while building the workspace without releasing any memory
>>> that is no longer needed.
>>>
>>> I already tried it with a completely new eclipse installation and a new
>>> workspace, but the problem still occurs.
>>>
>>> Is this a known problem? Or may this be caused by an external library we
>>> are using?
>>>
>> Look carefully at the .log messages when this happens - I'll bet it is
>> actually a PermGen space error, not a heap space problem.
>> If so, you'll need to set the max PermGen size in your eclipse.ini -
>> Google for how to do that, it is a much-discussed topic (the default
>> PermGen size on Sun JVMs is, unfortunately, very small).
>>
>> Hope this helps,
>> Eric
>>
>
>
>
--------------070200020805050403080203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dirk,<br>
<br>
In this case your heap is only -Xmx512M. I have about 180 plugins in
my workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
never run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor
the heap's growth as you use the workspace. It seems more likely that
you might have an editor that's leaking than that the build itself is
leaking the memory. The problem with memory exhaustion is that one
tends to blame the straw that broke the camel's back because it's the
most obvious, but it might not be the cause for the accumulation of
rest of the straw...<br>
<br>
<br>
Dirk Wenke wrote:
<blockquote cite="mid:fn6v7j$9sc$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Eric,
thanks for your help. But it does not look like a PermGen space problem. We
already tried to solve the problem by setting the maxPermSize, but that did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <a class="moz-txt-link-rfc2396E" href="mailto:eclipse-news@rizzoweb.com"><eclipse-news@rizzoweb.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn58dv$661$3@build.eclipse.org">news:fn58dv$661$3@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Dirk Wenke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
</pre>
</blockquote>
<pre wrap="">Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------070200020805050403080203--
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250857 is a reply to message #250842] |
Wed, 23 January 2008 05:45 |
| Eclipse User |
|
|
|
Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
>It seems like there exists some kind of memory leak. Initially we ran
>eclipse with -Xmx256m and after these problems we increased the maximum
>heap size up to 1GB, but eclipse is still running out of memory. In the
>preferences we enabled the display of the heap status: Normally eclipse
>occupies something between 100MB to 150MB but sometimes it occupies more
>and more memory while building the workspace without releasing any memory
>that is no longer needed.
This problem always occurs while building the workspace, never while running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens that
during the build of the workspace the used heap rapidly grows from 150MB up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But we
were not able to find out what change might be the cause of the problem. We
removed all new plugins from our workspace, because we thought that one of
our newer plugins is the cause for this problem, but eclipse still ran out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn704q$ggg$1@build.eclipse.org...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might have
an editor that's leaking than that the build itself is leaking the memory.
The problem with memory exhaustion is that one tends to blame the straw that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem. We
already tried to solve the problem by setting the maxPermSize, but that did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
news:fn58dv$661$3@build.eclipse.org...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250861 is a reply to message #250857] |
Wed, 23 January 2008 05:53 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020402050207040009050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dirk,
I see that now. Your problem does seem to be indicative of a bug
somewhere though. So you're saying that your heap isn't gradually
growing over time based on other activities (opening and closing
editors), but rather that some particular build kicks in that consumes a
lot of memory and after that the memory is not released, so the next
build is a bit worse, and so on until there's no space? But you're not
sure what causes this to happen because things are going fine for quite
a while first? And your not sure what change/activity first starts to
cause the heap to begin using more memory *and *not releasing it? I
think that little control can let you for a collection to happen...
Dirk Wenke wrote:
> Hi Ed,
>
> I am not saying that this is a bug in eclipse, otherwise I would have
> written a bug report. But I need somehow to find out what is causing this
> problem. Or at least how to avoid my eclipse running out of memory. This is
> why I writing to the newsgroups.
> We are already monitoring the heap status, which I wrote in my first
> message:
>
>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>
> This problem always occurs while building the workspace, never while running
> the runtime workbench or doing sth. else.
> Even if I am running eclipse with -Xmx1024M heap size it still happens that
> during the build of the workspace the used heap rapidly grows from 150MB up
> to 1000MB and then sometimes throws an OutOfMemory error. But even if
> eclipse is not running out of memory, only parts of the heap allocated
> during the workspace build is released.
> The strange thing is that we are developing with eclipse 3.2.1 since more
> than 1,5 years and this problem occured the first time 4 months ago. But we
> were not able to find out what change might be the cause of the problem. We
> removed all new plugins from our workspace, because we thought that one of
> our newer plugins is the cause for this problem, but eclipse still ran out
> of memory. So at this point we are really lost.
>
> Best,
>
> Dirk
>
>
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn704q$ggg$1@build.eclipse.org...
> Dirk,
>
> In this case your heap is only -Xmx512M. I have about 180 plugins in my
> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've never
> run out of heap space. You might want to use
> "Window->Preferences->General->Show heap status" and monitor the heap's
> growth as you use the workspace. It seems more likely that you might have
> an editor that's leaking than that the build itself is leaking the memory.
> The problem with memory exhaustion is that one tends to blame the straw that
> broke the camel's back because it's the most obvious, but it might not be
> the cause for the accumulation of rest of the straw...
>
>
> Dirk Wenke wrote:
> Hi Eric,
>
> thanks for your help. But it does not look like a PermGen space problem. We
> already tried to solve the problem by setting the maxPermSize, but that did
> not work.
> The exception logged to the eclipse .log looks like the following:
>
> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
> !MESSAGE Java heap space
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
> at
> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
> !SESSION 2007-12-04
> 09:28:52.562 -----------------------------------------------
> eclipse.buildId=M20060921-0945
> java.version=1.5.0_10
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Framework arguments: -Xmx512M
> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>
>
> Any other comments welcome :)
>
> Best,
>
> Dirk
>
>
>
> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
> news:fn58dv$661$3@build.eclipse.org...
>
> Dirk Wenke wrote:
>
> Hi,
>
> I currently have a problem with my eclipse running OutOfMemory while
> building the workspace.
> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
> JDK1.5.
> In the workspace we have something about 60 additionally plugins we are
> developing.
>
> This is a really strange problem, because it is not reproducible at all.
> You can work with eclipse for a week without any problems and on the next
> day it runs out of memory every half an hour. The problem only occurs
> while building the workspace.
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum
> heap size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more
> and more memory while building the workspace without releasing any memory
> that is no longer needed.
>
> I already tried it with a completely new eclipse installation and a new
> workspace, but the problem still occurs.
>
> Is this a known problem? Or may this be caused by an external library we
> are using?
>
> Look carefully at the .log messages when this happens - I'll bet it is
> actually a PermGen space error, not a heap space problem.
> If so, you'll need to set the max PermGen size in your eclipse.ini -
> Google for how to do that, it is a much-discussed topic (the default
> PermGen size on Sun JVMs is, unfortunately, very small).
>
> Hope this helps,
> Eric
>
>
>
>
>
>
>
--------------020402050207040009050009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dirk,<br>
<br>
I see that now. Your problem does seem to be indicative of a bug
somewhere though. So you're saying that your heap isn't gradually
growing over time based on other activities (opening and closing
editors), but rather that some particular build kicks in that consumes
a lot of memory and after that the memory is not released, so the next
build is a bit worse, and so on until there's no space? But you're not
sure what causes this to happen because things are going fine for quite
a while first? And your not sure what change/activity first starts to
cause the heap to begin using more memory <b>and </b>not releasing
it? I think that little control can let you for a collection to
happen...<br>
<br>
<br>
Dirk Wenke wrote:
<blockquote cite="mid:fn75ss$519$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
</pre>
<blockquote type="cite">
<pre wrap="">It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
</pre>
</blockquote>
<pre wrap=""><!---->
This problem always occurs while building the workspace, never while running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens that
during the build of the workspace the used heap rapidly grows from 150MB up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But we
were not able to find out what change might be the cause of the problem. We
removed all new plugins from our workspace, because we thought that one of
our newer plugins is the cause for this problem, but eclipse still ran out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn704q$ggg$1@build.eclipse.org">news:fn704q$ggg$1@build.eclipse.org</a>...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might have
an editor that's leaking than that the build itself is leaking the memory.
The problem with memory exhaustion is that one tends to blame the straw that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem. We
already tried to solve the problem by setting the maxPermSize, but that did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <a class="moz-txt-link-rfc2396E" href="mailto:eclipse-news@rizzoweb.com"><eclipse-news@rizzoweb.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn58dv$661$3@build.eclipse.org">news:fn58dv$661$3@build.eclipse.org</a>...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
</pre>
</blockquote>
<br>
</body>
</html>
--------------020402050207040009050009--
|
|
| | |
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250880 is a reply to message #250861] |
Wed, 23 January 2008 11:19 |
| Eclipse User |
|
|
|
Hi Ed,
I know that the little heap monitor has a button to force garbage
collection. But the garbage collection does not solve the Problem. The GC
does not seem to find many objects to destroy. So if the used memory is near
the max heap size and I force garbage collection, sth. between 30-50 MB are
released, but that's not much, if nearly 1000 MB are in use... So explicitly
forcing garbage collection does not prevent eclipse from running out of
memory.
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn76cg$98j$1@build.eclipse.org...
Dirk,
I see that now. Your problem does seem to be indicative of a bug somewhere
though. So you're saying that your heap isn't gradually growing over time
based on other activities (opening and closing editors), but rather that
some particular build kicks in that consumes a lot of memory and after that
the memory is not released, so the next build is a bit worse, and so on
until there's no space? But you're not sure what causes this to happen
because things are going fine for quite a while first? And your not sure
what change/activity first starts to cause the heap to begin using more
memory and not releasing it? I think that little control can let you for a
collection to happen...
Dirk Wenke wrote:
Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
This problem always occurs while building the workspace, never while running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens that
during the build of the workspace the used heap rapidly grows from 150MB up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But we
were not able to find out what change might be the cause of the problem. We
removed all new plugins from our workspace, because we thought that one of
our newer plugins is the cause for this problem, but eclipse still ran out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn704q$ggg$1@build.eclipse.org...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might have
an editor that's leaking than that the build itself is leaking the memory.
The problem with memory exhaustion is that one tends to blame the straw that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem. We
already tried to solve the problem by setting the maxPermSize, but that did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
news:fn58dv$661$3@build.eclipse.org...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
|
|
| |
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250888 is a reply to message #250880] |
Wed, 23 January 2008 12:19 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Dirk,
I'm just trying to help narrow the issue down so you can get it to the
stage of reproducibility and then open a bugzilla. Because I've never
see a problem like this with almost 200 plugins in my workspace, I'd be
suspicious of that style checker thing you have. Perhaps you might
disable that plugin and see if the problem persists.
Dirk Wenke wrote:
> Hi Ed,
>
> I know that the little heap monitor has a button to force garbage
> collection. But the garbage collection does not solve the Problem. The GC
> does not seem to find many objects to destroy. So if the used memory is near
> the max heap size and I force garbage collection, sth. between 30-50 MB are
> released, but that's not much, if nearly 1000 MB are in use... So explicitly
> forcing garbage collection does not prevent eclipse from running out of
> memory.
>
> Dirk
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn76cg$98j$1@build.eclipse.org...
> Dirk,
>
> I see that now. Your problem does seem to be indicative of a bug somewhere
> though. So you're saying that your heap isn't gradually growing over time
> based on other activities (opening and closing editors), but rather that
> some particular build kicks in that consumes a lot of memory and after that
> the memory is not released, so the next build is a bit worse, and so on
> until there's no space? But you're not sure what causes this to happen
> because things are going fine for quite a while first? And your not sure
> what change/activity first starts to cause the heap to begin using more
> memory and not releasing it? I think that little control can let you for a
> collection to happen...
>
>
> Dirk Wenke wrote:
> Hi Ed,
>
> I am not saying that this is a bug in eclipse, otherwise I would have
> written a bug report. But I need somehow to find out what is causing this
> problem. Or at least how to avoid my eclipse running out of memory. This is
> why I writing to the newsgroups.
> We are already monitoring the heap status, which I wrote in my first
> message:
>
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum
> heap size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more
> and more memory while building the workspace without releasing any memory
> that is no longer needed.
>
>
> This problem always occurs while building the workspace, never while running
> the runtime workbench or doing sth. else.
> Even if I am running eclipse with -Xmx1024M heap size it still happens that
> during the build of the workspace the used heap rapidly grows from 150MB up
> to 1000MB and then sometimes throws an OutOfMemory error. But even if
> eclipse is not running out of memory, only parts of the heap allocated
> during the workspace build is released.
> The strange thing is that we are developing with eclipse 3.2.1 since more
> than 1,5 years and this problem occured the first time 4 months ago. But we
> were not able to find out what change might be the cause of the problem. We
> removed all new plugins from our workspace, because we thought that one of
> our newer plugins is the cause for this problem, but eclipse still ran out
> of memory. So at this point we are really lost.
>
> Best,
>
> Dirk
>
>
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn704q$ggg$1@build.eclipse.org...
> Dirk,
>
> In this case your heap is only -Xmx512M. I have about 180 plugins in my
> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've never
> run out of heap space. You might want to use
> "Window->Preferences->General->Show heap status" and monitor the heap's
> growth as you use the workspace. It seems more likely that you might have
> an editor that's leaking than that the build itself is leaking the memory.
> The problem with memory exhaustion is that one tends to blame the straw that
> broke the camel's back because it's the most obvious, but it might not be
> the cause for the accumulation of rest of the straw...
>
>
> Dirk Wenke wrote:
> Hi Eric,
>
> thanks for your help. But it does not look like a PermGen space problem. We
> already tried to solve the problem by setting the maxPermSize, but that did
> not work.
> The exception logged to the eclipse .log looks like the following:
>
> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
> !MESSAGE Java heap space
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
> at
> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
> !SESSION 2007-12-04
> 09:28:52.562 -----------------------------------------------
> eclipse.buildId=M20060921-0945
> java.version=1.5.0_10
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Framework arguments: -Xmx512M
> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>
>
> Any other comments welcome :)
>
> Best,
>
> Dirk
>
>
>
> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
> news:fn58dv$661$3@build.eclipse.org...
>
> Dirk Wenke wrote:
>
> Hi,
>
> I currently have a problem with my eclipse running OutOfMemory while
> building the workspace.
> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
> JDK1.5.
> In the workspace we have something about 60 additionally plugins we are
> developing.
>
> This is a really strange problem, because it is not reproducible at all.
> You can work with eclipse for a week without any problems and on the next
> day it runs out of memory every half an hour. The problem only occurs
> while building the workspace.
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum
> heap size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more
> and more memory while building the workspace without releasing any memory
> that is no longer needed.
>
> I already tried it with a completely new eclipse installation and a new
> workspace, but the problem still occurs.
>
> Is this a known problem? Or may this be caused by an external library we
> are using?
>
> Look carefully at the .log messages when this happens - I'll bet it is
> actually a PermGen space error, not a heap space problem.
> If so, you'll need to set the max PermGen size in your eclipse.ini -
> Google for how to do that, it is a much-discussed topic (the default
> PermGen size on Sun JVMs is, unfortunately, very small).
>
> Hope this helps,
> Eric
>
>
>
>
>
>
>
>
>
>
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250909 is a reply to message #250888] |
Thu, 24 January 2008 04:01 |
| Eclipse User |
|
|
|
Hi Ed,
I removed all builders from our projects except for the JavaBuilder,
ManifestBuilder and SchemaBuilder.
But eclipse is unfortunatly still running out of memory :(
This morning I started eclipse (occupied 50-70MB after initialization),
synchronized with our CVS (I did not update anything, just wanted to commit
some changes) and while commiting the resources, eclipse started a workspace
build and within a minute the complete heap space was in use and eclipse ran
out of memory.
Currently I run eclipse with the following options
-vmargs
-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=512m
I decreased the max heap size and increased the size of the permanent
generation space. But that did as well not solve the problem.
Do you have any other suggestions?
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn7suv$lg3$2@build.eclipse.org...
> Dirk,
>
> I'm just trying to help narrow the issue down so you can get it to the
> stage of reproducibility and then open a bugzilla. Because I've never see
> a problem like this with almost 200 plugins in my workspace, I'd be
> suspicious of that style checker thing you have. Perhaps you might
> disable that plugin and see if the problem persists.
>
> Dirk Wenke wrote:
>> Hi Ed,
>>
>> I know that the little heap monitor has a button to force garbage
>> collection. But the garbage collection does not solve the Problem. The GC
>> does not seem to find many objects to destroy. So if the used memory is
>> near the max heap size and I force garbage collection, sth. between 30-50
>> MB are released, but that's not much, if nearly 1000 MB are in use... So
>> explicitly forcing garbage collection does not prevent eclipse from
>> running out of memory.
>>
>> Dirk
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn76cg$98j$1@build.eclipse.org...
>> Dirk,
>>
>> I see that now. Your problem does seem to be indicative of a bug
>> somewhere though. So you're saying that your heap isn't gradually
>> growing over time based on other activities (opening and closing
>> editors), but rather that some particular build kicks in that consumes a
>> lot of memory and after that the memory is not released, so the next
>> build is a bit worse, and so on until there's no space? But you're not
>> sure what causes this to happen because things are going fine for quite a
>> while first? And your not sure what change/activity first starts to
>> cause the heap to begin using more memory and not releasing it? I think
>> that little control can let you for a collection to happen...
>>
>>
>> Dirk Wenke wrote:
>> Hi Ed,
>>
>> I am not saying that this is a bug in eclipse, otherwise I would have
>> written a bug report. But I need somehow to find out what is causing this
>> problem. Or at least how to avoid my eclipse running out of memory. This
>> is
>> why I writing to the newsgroups.
>> We are already monitoring the heap status, which I wrote in my first
>> message:
>>
>>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>>
>> This problem always occurs while building the workspace, never while
>> running
>> the runtime workbench or doing sth. else.
>> Even if I am running eclipse with -Xmx1024M heap size it still happens
>> that
>> during the build of the workspace the used heap rapidly grows from 150MB
>> up
>> to 1000MB and then sometimes throws an OutOfMemory error. But even if
>> eclipse is not running out of memory, only parts of the heap allocated
>> during the workspace build is released.
>> The strange thing is that we are developing with eclipse 3.2.1 since more
>> than 1,5 years and this problem occured the first time 4 months ago. But
>> we
>> were not able to find out what change might be the cause of the problem.
>> We
>> removed all new plugins from our workspace, because we thought that one
>> of
>> our newer plugins is the cause for this problem, but eclipse still ran
>> out
>> of memory. So at this point we are really lost.
>>
>> Best,
>>
>> Dirk
>>
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn704q$ggg$1@build.eclipse.org...
>> Dirk,
>>
>> In this case your heap is only -Xmx512M. I have about 180 plugins in my
>> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
>> never
>> run out of heap space. You might want to use
>> "Window->Preferences->General->Show heap status" and monitor the heap's
>> growth as you use the workspace. It seems more likely that you might
>> have
>> an editor that's leaking than that the build itself is leaking the
>> memory.
>> The problem with memory exhaustion is that one tends to blame the straw
>> that
>> broke the camel's back because it's the most obvious, but it might not be
>> the cause for the accumulation of rest of the straw...
>>
>>
>> Dirk Wenke wrote:
>> Hi Eric,
>>
>> thanks for your help. But it does not look like a PermGen space problem.
>> We
>> already tried to solve the problem by setting the maxPermSize, but that
>> did
>> not work.
>> The exception logged to the eclipse .log looks like the following:
>>
>> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
>> !MESSAGE Java heap space
>> !STACK 0
>> java.lang.OutOfMemoryError: Java heap space
>> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
>> at
>> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
>> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
>> at
>> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
>> at
>> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
>> at
>> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
>> at
>> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
>> at
>> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
>> !SESSION 2007-12-04
>> 09:28:52.562 -----------------------------------------------
>> eclipse.buildId=M20060921-0945
>> java.version=1.5.0_10
>> java.vendor=Sun Microsystems Inc.
>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
>> Framework arguments: -Xmx512M
>> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>>
>>
>> Any other comments welcome :)
>>
>> Best,
>>
>> Dirk
>>
>>
>>
>> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
>> news:fn58dv$661$3@build.eclipse.org...
>>
>> Dirk Wenke wrote:
>>
>> Hi,
>>
>> I currently have a problem with my eclipse running OutOfMemory while
>> building the workspace.
>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>> JDK1.5.
>> In the workspace we have something about 60 additionally plugins we are
>> developing.
>>
>> This is a really strange problem, because it is not reproducible at all.
>> You can work with eclipse for a week without any problems and on the next
>> day it runs out of memory every half an hour. The problem only occurs
>> while building the workspace.
>>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>> I already tried it with a completely new eclipse installation and a new
>> workspace, but the problem still occurs.
>>
>> Is this a known problem? Or may this be caused by an external library we
>> are using?
>>
>> Look carefully at the .log messages when this happens - I'll bet it is
>> actually a PermGen space error, not a heap space problem.
>> If so, you'll need to set the max PermGen size in your eclipse.ini -
>> Google for how to do that, it is a much-discussed topic (the default
>> PermGen size on Sun JVMs is, unfortunately, very small).
>>
>> Hope this helps,
>> Eric
>>
>>
>>
>>
>>
>>
>>
>>
>>
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #250918 is a reply to message #250909] |
Thu, 24 January 2008 05:29 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020700060604060100030202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dirk,
If you can package up the problem in a reproducible way it would make a
great bugzilla report. I.e., a workspace for which repeated changes to
some file or set of files will gradually consume the heap would be
enough for someone else to see the problem. It might well be something
special about a particular Java construct you have in some file. Who
knows. I assume you've been monitoring the Error log for signs of
distress before things start to go wrong. Of course if you could run
your scenario using some kind of heap analysis tool to determine which
types of objects are leaking, that would be a big asset too and would
likely help point toward what component was producing all the leaked
information.
Of course I would be tempted to install the latest maintenance stream of
whatever version of Eclipse you are using and install in it only the
base platform SDK and try to reproduce the problem that way. Then I'd
gradually add any other plugins to the installation until the problem
starts to manifest again...
Dirk Wenke wrote:
> Hi Ed,
>
> I removed all builders from our projects except for the JavaBuilder,
> ManifestBuilder and SchemaBuilder.
> But eclipse is unfortunatly still running out of memory :(
> This morning I started eclipse (occupied 50-70MB after initialization),
> synchronized with our CVS (I did not update anything, just wanted to commit
> some changes) and while commiting the resources, eclipse started a workspace
> build and within a minute the complete heap space was in use and eclipse ran
> out of memory.
> Currently I run eclipse with the following options
>
> -vmargs
> -Xms512m
> -Xmx512m
> -XX:PermSize=256m
> -XX:MaxPermSize=512m
>
> I decreased the max heap size and increased the size of the permanent
> generation space. But that did as well not solve the problem.
> Do you have any other suggestions?
>
> Dirk
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn7suv$lg3$2@build.eclipse.org...
>
>> Dirk,
>>
>> I'm just trying to help narrow the issue down so you can get it to the
>> stage of reproducibility and then open a bugzilla. Because I've never see
>> a problem like this with almost 200 plugins in my workspace, I'd be
>> suspicious of that style checker thing you have. Perhaps you might
>> disable that plugin and see if the problem persists.
>>
>> Dirk Wenke wrote:
>>
>>> Hi Ed,
>>>
>>> I know that the little heap monitor has a button to force garbage
>>> collection. But the garbage collection does not solve the Problem. The GC
>>> does not seem to find many objects to destroy. So if the used memory is
>>> near the max heap size and I force garbage collection, sth. between 30-50
>>> MB are released, but that's not much, if nearly 1000 MB are in use... So
>>> explicitly forcing garbage collection does not prevent eclipse from
>>> running out of memory.
>>>
>>> Dirk
>>>
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn76cg$98j$1@build.eclipse.org...
>>> Dirk,
>>>
>>> I see that now. Your problem does seem to be indicative of a bug
>>> somewhere though. So you're saying that your heap isn't gradually
>>> growing over time based on other activities (opening and closing
>>> editors), but rather that some particular build kicks in that consumes a
>>> lot of memory and after that the memory is not released, so the next
>>> build is a bit worse, and so on until there's no space? But you're not
>>> sure what causes this to happen because things are going fine for quite a
>>> while first? And your not sure what change/activity first starts to
>>> cause the heap to begin using more memory and not releasing it? I think
>>> that little control can let you for a collection to happen...
>>>
>>>
>>> Dirk Wenke wrote:
>>> Hi Ed,
>>>
>>> I am not saying that this is a bug in eclipse, otherwise I would have
>>> written a bug report. But I need somehow to find out what is causing this
>>> problem. Or at least how to avoid my eclipse running out of memory. This
>>> is
>>> why I writing to the newsgroups.
>>> We are already monitoring the heap status, which I wrote in my first
>>> message:
>>>
>>>
>>> It seems like there exists some kind of memory leak. Initially we ran
>>> eclipse with -Xmx256m and after these problems we increased the maximum
>>> heap size up to 1GB, but eclipse is still running out of memory. In the
>>> preferences we enabled the display of the heap status: Normally eclipse
>>> occupies something between 100MB to 150MB but sometimes it occupies more
>>> and more memory while building the workspace without releasing any memory
>>> that is no longer needed.
>>>
>>>
>>> This problem always occurs while building the workspace, never while
>>> running
>>> the runtime workbench or doing sth. else.
>>> Even if I am running eclipse with -Xmx1024M heap size it still happens
>>> that
>>> during the build of the workspace the used heap rapidly grows from 150MB
>>> up
>>> to 1000MB and then sometimes throws an OutOfMemory error. But even if
>>> eclipse is not running out of memory, only parts of the heap allocated
>>> during the workspace build is released.
>>> The strange thing is that we are developing with eclipse 3.2.1 since more
>>> than 1,5 years and this problem occured the first time 4 months ago. But
>>> we
>>> were not able to find out what change might be the cause of the problem.
>>> We
>>> removed all new plugins from our workspace, because we thought that one
>>> of
>>> our newer plugins is the cause for this problem, but eclipse still ran
>>> out
>>> of memory. So at this point we are really lost.
>>>
>>> Best,
>>>
>>> Dirk
>>>
>>>
>>>
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn704q$ggg$1@build.eclipse.org...
>>> Dirk,
>>>
>>> In this case your heap is only -Xmx512M. I have about 180 plugins in my
>>> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
>>> never
>>> run out of heap space. You might want to use
>>> "Window->Preferences->General->Show heap status" and monitor the heap's
>>> growth as you use the workspace. It seems more likely that you might
>>> have
>>> an editor that's leaking than that the build itself is leaking the
>>> memory.
>>> The problem with memory exhaustion is that one tends to blame the straw
>>> that
>>> broke the camel's back because it's the most obvious, but it might not be
>>> the cause for the accumulation of rest of the straw...
>>>
>>>
>>> Dirk Wenke wrote:
>>> Hi Eric,
>>>
>>> thanks for your help. But it does not look like a PermGen space problem.
>>> We
>>> already tried to solve the problem by setting the maxPermSize, but that
>>> did
>>> not work.
>>> The exception logged to the eclipse .log looks like the following:
>>>
>>> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
>>> !MESSAGE Java heap space
>>> !STACK 0
>>> java.lang.OutOfMemoryError: Java heap space
>>> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
>>> at
>>> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
>>> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
>>> at
>>> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
>>> at
>>> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
>>> at
>>> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
>>> at
>>> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
>>> !SESSION 2007-12-04
>>> 09:28:52.562 -----------------------------------------------
>>> eclipse.buildId=M20060921-0945
>>> java.version=1.5.0_10
>>> java.vendor=Sun Microsystems Inc.
>>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
>>> Framework arguments: -Xmx512M
>>> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>>>
>>>
>>> Any other comments welcome :)
>>>
>>> Best,
>>>
>>> Dirk
>>>
>>>
>>>
>>> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
>>> news:fn58dv$661$3@build.eclipse.org...
>>>
>>> Dirk Wenke wrote:
>>>
>>> Hi,
>>>
>>> I currently have a problem with my eclipse running OutOfMemory while
>>> building the workspace.
>>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>>> JDK1.5.
>>> In the workspace we have something about 60 additionally plugins we are
>>> developing.
>>>
>>> This is a really strange problem, because it is not reproducible at all.
>>> You can work with eclipse for a week without any problems and on the next
>>> day it runs out of memory every half an hour. The problem only occurs
>>> while building the workspace.
>>>
>>> It seems like there exists some kind of memory leak. Initially we ran
>>> eclipse with -Xmx256m and after these problems we increased the maximum
>>> heap size up to 1GB, but eclipse is still running out of memory. In the
>>> preferences we enabled the display of the heap status: Normally eclipse
>>> occupies something between 100MB to 150MB but sometimes it occupies more
>>> and more memory while building the workspace without releasing any memory
>>> that is no longer needed.
>>>
>>> I already tried it with a completely new eclipse installation and a new
>>> workspace, but the problem still occurs.
>>>
>>> Is this a known problem? Or may this be caused by an external library we
>>> are using?
>>>
>>> Look carefully at the .log messages when this happens - I'll bet it is
>>> actually a PermGen space error, not a heap space problem.
>>> If so, you'll need to set the max PermGen size in your eclipse.ini -
>>> Google for how to do that, it is a much-discussed topic (the default
>>> PermGen size on Sun JVMs is, unfortunately, very small).
>>>
>>> Hope this helps,
>>> Eric
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
--------------020700060604060100030202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dirk,<br>
<br>
If you can package up the problem in a reproducible way it would make a
great bugzilla report. I.e., a workspace for which repeated changes to
some file or set of files will gradually consume the heap would be
enough for someone else to see the problem. It might well be something
special about a particular Java construct you have in some file. Who
knows. I assume you've been monitoring the Error log for signs of
distress before things start to go wrong. Of course if you could run
your scenario using some kind of heap analysis tool to determine which
types of objects are leaking, that would be a big asset too and would
likely help point toward what component was producing all the leaked
information. <br>
<br>
Of course I would be tempted to install the latest maintenance stream
of whatever version of Eclipse you are using and install in it only the
base platform SDK and try to reproduce the problem that way. Then I'd
gradually add any other plugins to the installation until the problem
starts to manifest again...<br>
<br>
<br>
Dirk Wenke wrote:
<blockquote cite="mid:fn9k4r$dvq$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I removed all builders from our projects except for the JavaBuilder,
ManifestBuilder and SchemaBuilder.
But eclipse is unfortunatly still running out of memory :(
This morning I started eclipse (occupied 50-70MB after initialization),
synchronized with our CVS (I did not update anything, just wanted to commit
some changes) and while commiting the resources, eclipse started a workspace
build and within a minute the complete heap space was in use and eclipse ran
out of memory.
Currently I run eclipse with the following options
-vmargs
-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=512m
I decreased the max heap size and increased the size of the permanent
generation space. But that did as well not solve the problem.
Do you have any other suggestions?
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn7suv$lg3$2@build.eclipse.org">news:fn7suv$lg3$2@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Dirk,
I'm just trying to help narrow the issue down so you can get it to the
stage of reproducibility and then open a bugzilla. Because I've never see
a problem like this with almost 200 plugins in my workspace, I'd be
suspicious of that style checker thing you have. Perhaps you might
disable that plugin and see if the problem persists.
Dirk Wenke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ed,
I know that the little heap monitor has a button to force garbage
collection. But the garbage collection does not solve the Problem. The GC
does not seem to find many objects to destroy. So if the used memory is
near the max heap size and I force garbage collection, sth. between 30-50
MB are released, but that's not much, if nearly 1000 MB are in use... So
explicitly forcing garbage collection does not prevent eclipse from
running out of memory.
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn76cg$98j$1@build.eclipse.org">news:fn76cg$98j$1@build.eclipse.org</a>...
Dirk,
I see that now. Your problem does seem to be indicative of a bug
somewhere though. So you're saying that your heap isn't gradually
growing over time based on other activities (opening and closing
editors), but rather that some particular build kicks in that consumes a
lot of memory and after that the memory is not released, so the next
build is a bit worse, and so on until there's no space? But you're not
sure what causes this to happen because things are going fine for quite a
while first? And your not sure what change/activity first starts to
cause the heap to begin using more memory and not releasing it? I think
that little control can let you for a collection to happen...
Dirk Wenke wrote:
Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This
is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
This problem always occurs while building the workspace, never while
running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens
that
during the build of the workspace the used heap rapidly grows from 150MB
up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But
we
were not able to find out what change might be the cause of the problem.
We
removed all new plugins from our workspace, because we thought that one
of
our newer plugins is the cause for this problem, but eclipse still ran
out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn704q$ggg$1@build.eclipse.org">news:fn704q$ggg$1@build.eclipse.org</a>...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might
have
an editor that's leaking than that the build itself is leaking the
memory.
The problem with memory exhaustion is that one tends to blame the straw
that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem.
We
already tried to solve the problem by setting the maxPermSize, but that
did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <a class="moz-txt-link-rfc2396E" href="mailto:eclipse-news@rizzoweb.com"><eclipse-news@rizzoweb.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn58dv$661$3@build.eclipse.org">news:fn58dv$661$3@build.eclipse.org</a>...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------020700060604060100030202--
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #251020 is a reply to message #250918] |
Mon, 28 January 2008 11:31 |
| Eclipse User |
|
|
|
Hi Ed,
I am now able to reproduce the OutOfMemory problem.
I start my eclipse and after initialisation it occupies around 50MB. Then I
delete 3 images that are contained in one of my plugins => eclipse starts a
build of the workspace and runs out of memory (with -Xmx512m). I profiled
this with JProfiler and saw, that most of the space is used for char[]
objects (376MB) and ClassPathAccessRule objects (74MB).
But I think that information does not help very much. Is there anything else
I can do? The problem is, that I cannot give away my workspace, because I
can't give away the source code of our major products.
Best,
Dirk
----
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn9pa3$2pt$1@build.eclipse.org...
Dirk,
If you can package up the problem in a reproducible way it would make a
great bugzilla report. I.e., a workspace for which repeated changes to some
file or set of files will gradually consume the heap would be enough for
someone else to see the problem. It might well be something special about a
particular Java construct you have in some file. Who knows. I assume
you've been monitoring the Error log for signs of distress before things
start to go wrong. Of course if you could run your scenario using some kind
of heap analysis tool to determine which types of objects are leaking, that
would be a big asset too and would likely help point toward what component
was producing all the leaked information.
Of course I would be tempted to install the latest maintenance stream of
whatever version of Eclipse you are using and install in it only the base
platform SDK and try to reproduce the problem that way. Then I'd gradually
add any other plugins to the installation until the problem starts to
manifest again...
Dirk Wenke wrote:
Hi Ed,
I removed all builders from our projects except for the JavaBuilder,
ManifestBuilder and SchemaBuilder.
But eclipse is unfortunatly still running out of memory :(
This morning I started eclipse (occupied 50-70MB after initialization),
synchronized with our CVS (I did not update anything, just wanted to commit
some changes) and while commiting the resources, eclipse started a workspace
build and within a minute the complete heap space was in use and eclipse ran
out of memory.
Currently I run eclipse with the following options
-vmargs
-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=512m
I decreased the max heap size and increased the size of the permanent
generation space. But that did as well not solve the problem.
Do you have any other suggestions?
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn7suv$lg3$2@build.eclipse.org...
Dirk,
I'm just trying to help narrow the issue down so you can get it to the
stage of reproducibility and then open a bugzilla. Because I've never see
a problem like this with almost 200 plugins in my workspace, I'd be
suspicious of that style checker thing you have. Perhaps you might
disable that plugin and see if the problem persists.
Dirk Wenke wrote:
Hi Ed,
I know that the little heap monitor has a button to force garbage
collection. But the garbage collection does not solve the Problem. The GC
does not seem to find many objects to destroy. So if the used memory is
near the max heap size and I force garbage collection, sth. between 30-50
MB are released, but that's not much, if nearly 1000 MB are in use... So
explicitly forcing garbage collection does not prevent eclipse from
running out of memory.
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn76cg$98j$1@build.eclipse.org...
Dirk,
I see that now. Your problem does seem to be indicative of a bug
somewhere though. So you're saying that your heap isn't gradually
growing over time based on other activities (opening and closing
editors), but rather that some particular build kicks in that consumes a
lot of memory and after that the memory is not released, so the next
build is a bit worse, and so on until there's no space? But you're not
sure what causes this to happen because things are going fine for quite a
while first? And your not sure what change/activity first starts to
cause the heap to begin using more memory and not releasing it? I think
that little control can let you for a collection to happen...
Dirk Wenke wrote:
Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This
is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
This problem always occurs while building the workspace, never while
running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens
that
during the build of the workspace the used heap rapidly grows from 150MB
up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But
we
were not able to find out what change might be the cause of the problem.
We
removed all new plugins from our workspace, because we thought that one
of
our newer plugins is the cause for this problem, but eclipse still ran
out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fn704q$ggg$1@build.eclipse.org...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might
have
an editor that's leaking than that the build itself is leaking the
memory.
The problem with memory exhaustion is that one tends to blame the straw
that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem.
We
already tried to solve the problem by setting the maxPermSize, but that
did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
news:fn58dv$661$3@build.eclipse.org...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #251031 is a reply to message #251020] |
Mon, 28 January 2008 14:55 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Dirk,
Maybe you can keep trimming down your workspace while still reproducing
your problem and have only dummy .java files and other crappy things
that are okay to attach to a bugzilla. It's odd that deleting an image
would do anything significant...
Dirk Wenke wrote:
> Hi Ed,
>
> I am now able to reproduce the OutOfMemory problem.
> I start my eclipse and after initialisation it occupies around 50MB. Then I
> delete 3 images that are contained in one of my plugins => eclipse starts a
> build of the workspace and runs out of memory (with -Xmx512m). I profiled
> this with JProfiler and saw, that most of the space is used for char[]
> objects (376MB) and ClassPathAccessRule objects (74MB).
> But I think that information does not help very much. Is there anything else
> I can do? The problem is, that I cannot give away my workspace, because I
> can't give away the source code of our major products.
>
> Best,
>
> Dirk
>
> ----
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn9pa3$2pt$1@build.eclipse.org...
> Dirk,
>
> If you can package up the problem in a reproducible way it would make a
> great bugzilla report. I.e., a workspace for which repeated changes to some
> file or set of files will gradually consume the heap would be enough for
> someone else to see the problem. It might well be something special about a
> particular Java construct you have in some file. Who knows. I assume
> you've been monitoring the Error log for signs of distress before things
> start to go wrong. Of course if you could run your scenario using some kind
> of heap analysis tool to determine which types of objects are leaking, that
> would be a big asset too and would likely help point toward what component
> was producing all the leaked information.
>
> Of course I would be tempted to install the latest maintenance stream of
> whatever version of Eclipse you are using and install in it only the base
> platform SDK and try to reproduce the problem that way. Then I'd gradually
> add any other plugins to the installation until the problem starts to
> manifest again...
>
>
> Dirk Wenke wrote:
> Hi Ed,
>
> I removed all builders from our projects except for the JavaBuilder,
> ManifestBuilder and SchemaBuilder.
> But eclipse is unfortunatly still running out of memory :(
> This morning I started eclipse (occupied 50-70MB after initialization),
> synchronized with our CVS (I did not update anything, just wanted to commit
> some changes) and while commiting the resources, eclipse started a workspace
> build and within a minute the complete heap space was in use and eclipse ran
> out of memory.
> Currently I run eclipse with the following options
>
> -vmargs
> -Xms512m
> -Xmx512m
> -XX:PermSize=256m
> -XX:MaxPermSize=512m
>
> I decreased the max heap size and increased the size of the permanent
> generation space. But that did as well not solve the problem.
> Do you have any other suggestions?
>
> Dirk
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn7suv$lg3$2@build.eclipse.org...
>
> Dirk,
>
> I'm just trying to help narrow the issue down so you can get it to the
> stage of reproducibility and then open a bugzilla. Because I've never see
> a problem like this with almost 200 plugins in my workspace, I'd be
> suspicious of that style checker thing you have. Perhaps you might
> disable that plugin and see if the problem persists.
>
> Dirk Wenke wrote:
>
> Hi Ed,
>
> I know that the little heap monitor has a button to force garbage
> collection. But the garbage collection does not solve the Problem. The GC
> does not seem to find many objects to destroy. So if the used memory is
> near the max heap size and I force garbage collection, sth. between 30-50
> MB are released, but that's not much, if nearly 1000 MB are in use... So
> explicitly forcing garbage collection does not prevent eclipse from
> running out of memory.
>
> Dirk
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn76cg$98j$1@build.eclipse.org...
> Dirk,
>
> I see that now. Your problem does seem to be indicative of a bug
> somewhere though. So you're saying that your heap isn't gradually
> growing over time based on other activities (opening and closing
> editors), but rather that some particular build kicks in that consumes a
> lot of memory and after that the memory is not released, so the next
> build is a bit worse, and so on until there's no space? But you're not
> sure what causes this to happen because things are going fine for quite a
> while first? And your not sure what change/activity first starts to
> cause the heap to begin using more memory and not releasing it? I think
> that little control can let you for a collection to happen...
>
>
> Dirk Wenke wrote:
> Hi Ed,
>
> I am not saying that this is a bug in eclipse, otherwise I would have
> written a bug report. But I need somehow to find out what is causing this
> problem. Or at least how to avoid my eclipse running out of memory. This
> is
> why I writing to the newsgroups.
> We are already monitoring the heap status, which I wrote in my first
> message:
>
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum
> heap size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more
> and more memory while building the workspace without releasing any memory
> that is no longer needed.
>
>
> This problem always occurs while building the workspace, never while
> running
> the runtime workbench or doing sth. else.
> Even if I am running eclipse with -Xmx1024M heap size it still happens
> that
> during the build of the workspace the used heap rapidly grows from 150MB
> up
> to 1000MB and then sometimes throws an OutOfMemory error. But even if
> eclipse is not running out of memory, only parts of the heap allocated
> during the workspace build is released.
> The strange thing is that we are developing with eclipse 3.2.1 since more
> than 1,5 years and this problem occured the first time 4 months ago. But
> we
> were not able to find out what change might be the cause of the problem.
> We
> removed all new plugins from our workspace, because we thought that one
> of
> our newer plugins is the cause for this problem, but eclipse still ran
> out
> of memory. So at this point we are really lost.
>
> Best,
>
> Dirk
>
>
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fn704q$ggg$1@build.eclipse.org...
> Dirk,
>
> In this case your heap is only -Xmx512M. I have about 180 plugins in my
> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
> never
> run out of heap space. You might want to use
> "Window->Preferences->General->Show heap status" and monitor the heap's
> growth as you use the workspace. It seems more likely that you might
> have
> an editor that's leaking than that the build itself is leaking the
> memory.
> The problem with memory exhaustion is that one tends to blame the straw
> that
> broke the camel's back because it's the most obvious, but it might not be
> the cause for the accumulation of rest of the straw...
>
>
> Dirk Wenke wrote:
> Hi Eric,
>
> thanks for your help. But it does not look like a PermGen space problem.
> We
> already tried to solve the problem by setting the maxPermSize, but that
> did
> not work.
> The exception logged to the eclipse .log looks like the following:
>
> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
> !MESSAGE Java heap space
> !STACK 0
> java.lang.OutOfMemoryError: Java heap space
> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
> at
> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
> !SESSION 2007-12-04
> 09:28:52.562 -----------------------------------------------
> eclipse.buildId=M20060921-0945
> java.version=1.5.0_10
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Framework arguments: -Xmx512M
> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>
>
> Any other comments welcome :)
>
> Best,
>
> Dirk
>
>
>
> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
> news:fn58dv$661$3@build.eclipse.org...
>
> Dirk Wenke wrote:
>
> Hi,
>
> I currently have a problem with my eclipse running OutOfMemory while
> building the workspace.
> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
> JDK1.5.
> In the workspace we have something about 60 additionally plugins we are
> developing.
>
> This is a really strange problem, because it is not reproducible at all.
> You can work with eclipse for a week without any problems and on the next
> day it runs out of memory every half an hour. The problem only occurs
> while building the workspace.
>
> It seems like there exists some kind of memory leak. Initially we ran
> eclipse with -Xmx256m and after these problems we increased the maximum
> heap size up to 1GB, but eclipse is still running out of memory. In the
> preferences we enabled the display of the heap status: Normally eclipse
> occupies something between 100MB to 150MB but sometimes it occupies more
> and more memory while building the workspace without releasing any memory
> that is no longer needed.
>
> I already tried it with a completely new eclipse installation and a new
> workspace, but the problem still occurs.
>
> Is this a known problem? Or may this be caused by an external library we
> are using?
>
> Look carefully at the .log messages when this happens - I'll bet it is
> actually a PermGen space error, not a heap space problem.
> If so, you'll need to set the max PermGen size in your eclipse.ini -
> Google for how to do that, it is a much-discussed topic (the default
> PermGen size on Sun JVMs is, unfortunately, very small).
>
> Hope this helps,
> Eric
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
| |
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #251157 is a reply to message #251031] |
Thu, 31 January 2008 10:17 |
| Eclipse User |
|
|
|
Hi Ed,
I think we found the cause of the problem.
We started eclipse with -XX:+HeapDumpOnOutOfMemoryError and analyzed the
heap dump afterwards with the memory analyzer provided by SAP.
Nearly all heap space is allocated by a HashMap in the JavaModelManager.
Taking a deeper look at this HashMap, we found out that most of the space is
needed for org.eclipse.jdt.internal.compiler.env.AccessRule arrays.
The really strange thing is, that many of these arrays exist but nearly all
having the same size and containing the same elements. This looks like a bug
to me.
Nevertheless the question still is why this only occurs in our environment.
But the reason for this seems to be located in our architecture, so let me
say a few words about the architecture of our plugins.
We have one main plugin containing all external libraries (in the first step
we placed the external libraries directly in the plugins that needed them,
but most of the libraries were required by multiple plugins and that lead to
plugins having different versions of the same library, etc.). This plugin
contains about 80 external jars and is exporting around 1600 packages. And
that is approximately the size of all the AccessRule arrays.
So I think we now know to prevent our eclipse from running out of memory, by
removing as many packages from the 'exported packages' and maybe deviding up
the external libraries between several plugins. But I still think that this
is a major bug in eclipse, isn't it?
Dirk
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
news:fnlc06$j8f$2@build.eclipse.org...
> Dirk,
>
> Maybe you can keep trimming down your workspace while still reproducing
> your problem and have only dummy .java files and other crappy things that
> are okay to attach to a bugzilla. It's odd that deleting an image would
> do anything significant...
>
>
> Dirk Wenke wrote:
>> Hi Ed,
>>
>> I am now able to reproduce the OutOfMemory problem.
>> I start my eclipse and after initialisation it occupies around 50MB. Then
>> I delete 3 images that are contained in one of my plugins => eclipse
>> starts a build of the workspace and runs out of memory (with -Xmx512m). I
>> profiled this with JProfiler and saw, that most of the space is used for
>> char[] objects (376MB) and ClassPathAccessRule objects (74MB).
>> But I think that information does not help very much. Is there anything
>> else I can do? The problem is, that I cannot give away my workspace,
>> because I can't give away the source code of our major products.
>>
>> Best,
>>
>> Dirk
>>
>> ----
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn9pa3$2pt$1@build.eclipse.org...
>> Dirk,
>>
>> If you can package up the problem in a reproducible way it would make a
>> great bugzilla report. I.e., a workspace for which repeated changes to
>> some file or set of files will gradually consume the heap would be enough
>> for someone else to see the problem. It might well be something special
>> about a particular Java construct you have in some file. Who knows. I
>> assume you've been monitoring the Error log for signs of distress before
>> things start to go wrong. Of course if you could run your scenario using
>> some kind of heap analysis tool to determine which types of objects are
>> leaking, that would be a big asset too and would likely help point toward
>> what component was producing all the leaked information.
>>
>> Of course I would be tempted to install the latest maintenance stream of
>> whatever version of Eclipse you are using and install in it only the base
>> platform SDK and try to reproduce the problem that way. Then I'd
>> gradually add any other plugins to the installation until the problem
>> starts to manifest again...
>>
>>
>> Dirk Wenke wrote:
>> Hi Ed,
>>
>> I removed all builders from our projects except for the JavaBuilder,
>> ManifestBuilder and SchemaBuilder.
>> But eclipse is unfortunatly still running out of memory :(
>> This morning I started eclipse (occupied 50-70MB after initialization),
>> synchronized with our CVS (I did not update anything, just wanted to
>> commit
>> some changes) and while commiting the resources, eclipse started a
>> workspace
>> build and within a minute the complete heap space was in use and eclipse
>> ran
>> out of memory.
>> Currently I run eclipse with the following options
>>
>> -vmargs
>> -Xms512m
>> -Xmx512m
>> -XX:PermSize=256m
>> -XX:MaxPermSize=512m
>>
>> I decreased the max heap size and increased the size of the permanent
>> generation space. But that did as well not solve the problem.
>> Do you have any other suggestions?
>>
>> Dirk
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn7suv$lg3$2@build.eclipse.org...
>>
>> Dirk,
>>
>> I'm just trying to help narrow the issue down so you can get it to the
>> stage of reproducibility and then open a bugzilla. Because I've never
>> see
>> a problem like this with almost 200 plugins in my workspace, I'd be
>> suspicious of that style checker thing you have. Perhaps you might
>> disable that plugin and see if the problem persists.
>>
>> Dirk Wenke wrote:
>>
>> Hi Ed,
>>
>> I know that the little heap monitor has a button to force garbage
>> collection. But the garbage collection does not solve the Problem. The GC
>> does not seem to find many objects to destroy. So if the used memory is
>> near the max heap size and I force garbage collection, sth. between 30-50
>> MB are released, but that's not much, if nearly 1000 MB are in use... So
>> explicitly forcing garbage collection does not prevent eclipse from
>> running out of memory.
>>
>> Dirk
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn76cg$98j$1@build.eclipse.org...
>> Dirk,
>>
>> I see that now. Your problem does seem to be indicative of a bug
>> somewhere though. So you're saying that your heap isn't gradually
>> growing over time based on other activities (opening and closing
>> editors), but rather that some particular build kicks in that consumes a
>> lot of memory and after that the memory is not released, so the next
>> build is a bit worse, and so on until there's no space? But you're not
>> sure what causes this to happen because things are going fine for quite a
>> while first? And your not sure what change/activity first starts to
>> cause the heap to begin using more memory and not releasing it? I think
>> that little control can let you for a collection to happen...
>>
>>
>> Dirk Wenke wrote:
>> Hi Ed,
>>
>> I am not saying that this is a bug in eclipse, otherwise I would have
>> written a bug report. But I need somehow to find out what is causing this
>> problem. Or at least how to avoid my eclipse running out of memory. This
>> is
>> why I writing to the newsgroups.
>> We are already monitoring the heap status, which I wrote in my first
>> message:
>>
>>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>>
>> This problem always occurs while building the workspace, never while
>> running
>> the runtime workbench or doing sth. else.
>> Even if I am running eclipse with -Xmx1024M heap size it still happens
>> that
>> during the build of the workspace the used heap rapidly grows from 150MB
>> up
>> to 1000MB and then sometimes throws an OutOfMemory error. But even if
>> eclipse is not running out of memory, only parts of the heap allocated
>> during the workspace build is released.
>> The strange thing is that we are developing with eclipse 3.2.1 since more
>> than 1,5 years and this problem occured the first time 4 months ago. But
>> we
>> were not able to find out what change might be the cause of the problem.
>> We
>> removed all new plugins from our workspace, because we thought that one
>> of
>> our newer plugins is the cause for this problem, but eclipse still ran
>> out
>> of memory. So at this point we are really lost.
>>
>> Best,
>>
>> Dirk
>>
>>
>>
>>
>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>> news:fn704q$ggg$1@build.eclipse.org...
>> Dirk,
>>
>> In this case your heap is only -Xmx512M. I have about 180 plugins in my
>> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
>> never
>> run out of heap space. You might want to use
>> "Window->Preferences->General->Show heap status" and monitor the heap's
>> growth as you use the workspace. It seems more likely that you might
>> have
>> an editor that's leaking than that the build itself is leaking the
>> memory.
>> The problem with memory exhaustion is that one tends to blame the straw
>> that
>> broke the camel's back because it's the most obvious, but it might not be
>> the cause for the accumulation of rest of the straw...
>>
>>
>> Dirk Wenke wrote:
>> Hi Eric,
>>
>> thanks for your help. But it does not look like a PermGen space problem.
>> We
>> already tried to solve the problem by setting the maxPermSize, but that
>> did
>> not work.
>> The exception logged to the eclipse .log looks like the following:
>>
>> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
>> !MESSAGE Java heap space
>> !STACK 0
>> java.lang.OutOfMemoryError: Java heap space
>> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
>> at
>> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
>> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
>> at
>> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
>> at
>> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
>> at
>> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
>> at
>> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
>> at
>> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
>> at
>> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
>> at
>> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
>> !SESSION 2007-12-04
>> 09:28:52.562 -----------------------------------------------
>> eclipse.buildId=M20060921-0945
>> java.version=1.5.0_10
>> java.vendor=Sun Microsystems Inc.
>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
>> Framework arguments: -Xmx512M
>> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>>
>>
>> Any other comments welcome :)
>>
>> Best,
>>
>> Dirk
>>
>>
>>
>> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
>> news:fn58dv$661$3@build.eclipse.org...
>>
>> Dirk Wenke wrote:
>>
>> Hi,
>>
>> I currently have a problem with my eclipse running OutOfMemory while
>> building the workspace.
>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>> JDK1.5.
>> In the workspace we have something about 60 additionally plugins we are
>> developing.
>>
>> This is a really strange problem, because it is not reproducible at all.
>> You can work with eclipse for a week without any problems and on the next
>> day it runs out of memory every half an hour. The problem only occurs
>> while building the workspace.
>>
>> It seems like there exists some kind of memory leak. Initially we ran
>> eclipse with -Xmx256m and after these problems we increased the maximum
>> heap size up to 1GB, but eclipse is still running out of memory. In the
>> preferences we enabled the display of the heap status: Normally eclipse
>> occupies something between 100MB to 150MB but sometimes it occupies more
>> and more memory while building the workspace without releasing any memory
>> that is no longer needed.
>>
>> I already tried it with a completely new eclipse installation and a new
>> workspace, but the problem still occurs.
>>
>> Is this a known problem? Or may this be caused by an external library we
>> are using?
>>
>> Look carefully at the .log messages when this happens - I'll bet it is
>> actually a PermGen space error, not a heap space problem.
>> If so, you'll need to set the max PermGen size in your eclipse.ini -
>> Google for how to do that, it is a much-discussed topic (the default
>> PermGen size on Sun JVMs is, unfortunately, very small).
>>
>> Hope this helps,
>> Eric
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #251168 is a reply to message #251157] |
Thu, 31 January 2008 11:59 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------060202030303000301060003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dirk,
It sounds like a bit of a scaling issue that might not have been
anticipated by the framework. I'm not sure how best to report the
problem. Can you share the setup? Can you mock it up? Smaller
plugins with minimal exports would seem like a good way to go in any case...
Dirk Wenke wrote:
> Hi Ed,
>
> I think we found the cause of the problem.
> We started eclipse with -XX:+HeapDumpOnOutOfMemoryError and analyzed the
> heap dump afterwards with the memory analyzer provided by SAP.
> Nearly all heap space is allocated by a HashMap in the JavaModelManager.
> Taking a deeper look at this HashMap, we found out that most of the space is
> needed for org.eclipse.jdt.internal.compiler.env.AccessRule arrays.
> The really strange thing is, that many of these arrays exist but nearly all
> having the same size and containing the same elements. This looks like a bug
> to me.
> Nevertheless the question still is why this only occurs in our environment.
> But the reason for this seems to be located in our architecture, so let me
> say a few words about the architecture of our plugins.
> We have one main plugin containing all external libraries (in the first step
> we placed the external libraries directly in the plugins that needed them,
> but most of the libraries were required by multiple plugins and that lead to
> plugins having different versions of the same library, etc.). This plugin
> contains about 80 external jars and is exporting around 1600 packages. And
> that is approximately the size of all the AccessRule arrays.
>
> So I think we now know to prevent our eclipse from running out of memory, by
> removing as many packages from the 'exported packages' and maybe deviding up
> the external libraries between several plugins. But I still think that this
> is a major bug in eclipse, isn't it?
>
> Dirk
>
>
> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
> news:fnlc06$j8f$2@build.eclipse.org...
>
>> Dirk,
>>
>> Maybe you can keep trimming down your workspace while still reproducing
>> your problem and have only dummy .java files and other crappy things that
>> are okay to attach to a bugzilla. It's odd that deleting an image would
>> do anything significant...
>>
>>
>> Dirk Wenke wrote:
>>
>>> Hi Ed,
>>>
>>> I am now able to reproduce the OutOfMemory problem.
>>> I start my eclipse and after initialisation it occupies around 50MB. Then
>>> I delete 3 images that are contained in one of my plugins => eclipse
>>> starts a build of the workspace and runs out of memory (with -Xmx512m). I
>>> profiled this with JProfiler and saw, that most of the space is used for
>>> char[] objects (376MB) and ClassPathAccessRule objects (74MB).
>>> But I think that information does not help very much. Is there anything
>>> else I can do? The problem is, that I cannot give away my workspace,
>>> because I can't give away the source code of our major products.
>>>
>>> Best,
>>>
>>> Dirk
>>>
>>> ----
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn9pa3$2pt$1@build.eclipse.org...
>>> Dirk,
>>>
>>> If you can package up the problem in a reproducible way it would make a
>>> great bugzilla report. I.e., a workspace for which repeated changes to
>>> some file or set of files will gradually consume the heap would be enough
>>> for someone else to see the problem. It might well be something special
>>> about a particular Java construct you have in some file. Who knows. I
>>> assume you've been monitoring the Error log for signs of distress before
>>> things start to go wrong. Of course if you could run your scenario using
>>> some kind of heap analysis tool to determine which types of objects are
>>> leaking, that would be a big asset too and would likely help point toward
>>> what component was producing all the leaked information.
>>>
>>> Of course I would be tempted to install the latest maintenance stream of
>>> whatever version of Eclipse you are using and install in it only the base
>>> platform SDK and try to reproduce the problem that way. Then I'd
>>> gradually add any other plugins to the installation until the problem
>>> starts to manifest again...
>>>
>>>
>>> Dirk Wenke wrote:
>>> Hi Ed,
>>>
>>> I removed all builders from our projects except for the JavaBuilder,
>>> ManifestBuilder and SchemaBuilder.
>>> But eclipse is unfortunatly still running out of memory :(
>>> This morning I started eclipse (occupied 50-70MB after initialization),
>>> synchronized with our CVS (I did not update anything, just wanted to
>>> commit
>>> some changes) and while commiting the resources, eclipse started a
>>> workspace
>>> build and within a minute the complete heap space was in use and eclipse
>>> ran
>>> out of memory.
>>> Currently I run eclipse with the following options
>>>
>>> -vmargs
>>> -Xms512m
>>> -Xmx512m
>>> -XX:PermSize=256m
>>> -XX:MaxPermSize=512m
>>>
>>> I decreased the max heap size and increased the size of the permanent
>>> generation space. But that did as well not solve the problem.
>>> Do you have any other suggestions?
>>>
>>> Dirk
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn7suv$lg3$2@build.eclipse.org...
>>>
>>> Dirk,
>>>
>>> I'm just trying to help narrow the issue down so you can get it to the
>>> stage of reproducibility and then open a bugzilla. Because I've never
>>> see
>>> a problem like this with almost 200 plugins in my workspace, I'd be
>>> suspicious of that style checker thing you have. Perhaps you might
>>> disable that plugin and see if the problem persists.
>>>
>>> Dirk Wenke wrote:
>>>
>>> Hi Ed,
>>>
>>> I know that the little heap monitor has a button to force garbage
>>> collection. But the garbage collection does not solve the Problem. The GC
>>> does not seem to find many objects to destroy. So if the used memory is
>>> near the max heap size and I force garbage collection, sth. between 30-50
>>> MB are released, but that's not much, if nearly 1000 MB are in use... So
>>> explicitly forcing garbage collection does not prevent eclipse from
>>> running out of memory.
>>>
>>> Dirk
>>>
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn76cg$98j$1@build.eclipse.org...
>>> Dirk,
>>>
>>> I see that now. Your problem does seem to be indicative of a bug
>>> somewhere though. So you're saying that your heap isn't gradually
>>> growing over time based on other activities (opening and closing
>>> editors), but rather that some particular build kicks in that consumes a
>>> lot of memory and after that the memory is not released, so the next
>>> build is a bit worse, and so on until there's no space? But you're not
>>> sure what causes this to happen because things are going fine for quite a
>>> while first? And your not sure what change/activity first starts to
>>> cause the heap to begin using more memory and not releasing it? I think
>>> that little control can let you for a collection to happen...
>>>
>>>
>>> Dirk Wenke wrote:
>>> Hi Ed,
>>>
>>> I am not saying that this is a bug in eclipse, otherwise I would have
>>> written a bug report. But I need somehow to find out what is causing this
>>> problem. Or at least how to avoid my eclipse running out of memory. This
>>> is
>>> why I writing to the newsgroups.
>>> We are already monitoring the heap status, which I wrote in my first
>>> message:
>>>
>>>
>>> It seems like there exists some kind of memory leak. Initially we ran
>>> eclipse with -Xmx256m and after these problems we increased the maximum
>>> heap size up to 1GB, but eclipse is still running out of memory. In the
>>> preferences we enabled the display of the heap status: Normally eclipse
>>> occupies something between 100MB to 150MB but sometimes it occupies more
>>> and more memory while building the workspace without releasing any memory
>>> that is no longer needed.
>>>
>>>
>>> This problem always occurs while building the workspace, never while
>>> running
>>> the runtime workbench or doing sth. else.
>>> Even if I am running eclipse with -Xmx1024M heap size it still happens
>>> that
>>> during the build of the workspace the used heap rapidly grows from 150MB
>>> up
>>> to 1000MB and then sometimes throws an OutOfMemory error. But even if
>>> eclipse is not running out of memory, only parts of the heap allocated
>>> during the workspace build is released.
>>> The strange thing is that we are developing with eclipse 3.2.1 since more
>>> than 1,5 years and this problem occured the first time 4 months ago. But
>>> we
>>> were not able to find out what change might be the cause of the problem.
>>> We
>>> removed all new plugins from our workspace, because we thought that one
>>> of
>>> our newer plugins is the cause for this problem, but eclipse still ran
>>> out
>>> of memory. So at this point we are really lost.
>>>
>>> Best,
>>>
>>> Dirk
>>>
>>>
>>>
>>>
>>> "Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag
>>> news:fn704q$ggg$1@build.eclipse.org...
>>> Dirk,
>>>
>>> In this case your heap is only -Xmx512M. I have about 180 plugins in my
>>> workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
>>> never
>>> run out of heap space. You might want to use
>>> "Window->Preferences->General->Show heap status" and monitor the heap's
>>> growth as you use the workspace. It seems more likely that you might
>>> have
>>> an editor that's leaking than that the build itself is leaking the
>>> memory.
>>> The problem with memory exhaustion is that one tends to blame the straw
>>> that
>>> broke the camel's back because it's the most obvious, but it might not be
>>> the cause for the accumulation of rest of the straw...
>>>
>>>
>>> Dirk Wenke wrote:
>>> Hi Eric,
>>>
>>> thanks for your help. But it does not look like a PermGen space problem.
>>> We
>>> already tried to solve the problem by setting the maxPermSize, but that
>>> did
>>> not work.
>>> The exception logged to the eclipse .log looks like the following:
>>>
>>> !ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
>>> !MESSAGE Java heap space
>>> !STACK 0
>>> java.lang.OutOfMemoryError: Java heap space
>>> at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
>>> at
>>> org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
>>> at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
>>> at
>>> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
>>> at
>>> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
>>> at
>>> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
>>> at
>>> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
>>> at
>>> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
>>> at
>>> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
>>> !SESSION 2007-12-04
>>> 09:28:52.562 -----------------------------------------------
>>> eclipse.buildId=M20060921-0945
>>> java.version=1.5.0_10
>>> java.vendor=Sun Microsystems Inc.
>>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
>>> Framework arguments: -Xmx512M
>>> Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
>>>
>>>
>>> Any other comments welcome :)
>>>
>>> Best,
>>>
>>> Dirk
>>>
>>>
>>>
>>> "Eric Rizzo" <eclipse-news@rizzoweb.com> schrieb im Newsbeitrag
>>> news:fn58dv$661$3@build.eclipse.org...
>>>
>>> Dirk Wenke wrote:
>>>
>>> Hi,
>>>
>>> I currently have a problem with my eclipse running OutOfMemory while
>>> building the workspace.
>>> I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
>>> JDK1.5.
>>> In the workspace we have something about 60 additionally plugins we are
>>> developing.
>>>
>>> This is a really strange problem, because it is not reproducible at all.
>>> You can work with eclipse for a week without any problems and on the next
>>> day it runs out of memory every half an hour. The problem only occurs
>>> while building the workspace.
>>>
>>> It seems like there exists some kind of memory leak. Initially we ran
>>> eclipse with -Xmx256m and after these problems we increased the maximum
>>> heap size up to 1GB, but eclipse is still running out of memory. In the
>>> preferences we enabled the display of the heap status: Normally eclipse
>>> occupies something between 100MB to 150MB but sometimes it occupies more
>>> and more memory while building the workspace without releasing any memory
>>> that is no longer needed.
>>>
>>> I already tried it with a completely new eclipse installation and a new
>>> workspace, but the problem still occurs.
>>>
>>> Is this a known problem? Or may this be caused by an external library we
>>> are using?
>>>
>>> Look carefully at the .log messages when this happens - I'll bet it is
>>> actually a PermGen space error, not a heap space problem.
>>> If so, you'll need to set the max PermGen size in your eclipse.ini -
>>> Google for how to do that, it is a much-discussed topic (the default
>>> PermGen size on Sun JVMs is, unfortunately, very small).
>>>
>>> Hope this helps,
>>> Eric
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
--------------060202030303000301060003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dirk,<br>
<br>
It sounds like a bit of a scaling issue that might not have been
anticipated by the framework. I'm not sure how best to report the
problem. Can you share the setup? Can you mock it up? Smaller
plugins with minimal exports would seem like a good way to go in any
case...<br>
<br>
<br>
Dirk Wenke wrote:
<blockquote cite="mid:fnsoqn$702$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I think we found the cause of the problem.
We started eclipse with -XX:+HeapDumpOnOutOfMemoryError and analyzed the
heap dump afterwards with the memory analyzer provided by SAP.
Nearly all heap space is allocated by a HashMap in the JavaModelManager.
Taking a deeper look at this HashMap, we found out that most of the space is
needed for org.eclipse.jdt.internal.compiler.env.AccessRule arrays.
The really strange thing is, that many of these arrays exist but nearly all
having the same size and containing the same elements. This looks like a bug
to me.
Nevertheless the question still is why this only occurs in our environment.
But the reason for this seems to be located in our architecture, so let me
say a few words about the architecture of our plugins.
We have one main plugin containing all external libraries (in the first step
we placed the external libraries directly in the plugins that needed them,
but most of the libraries were required by multiple plugins and that lead to
plugins having different versions of the same library, etc.). This plugin
contains about 80 external jars and is exporting around 1600 packages. And
that is approximately the size of all the AccessRule arrays.
So I think we now know to prevent our eclipse from running out of memory, by
removing as many packages from the 'exported packages' and maybe deviding up
the external libraries between several plugins. But I still think that this
is a major bug in eclipse, isn't it?
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fnlc06$j8f$2@build.eclipse.org">news:fnlc06$j8f$2@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Dirk,
Maybe you can keep trimming down your workspace while still reproducing
your problem and have only dummy .java files and other crappy things that
are okay to attach to a bugzilla. It's odd that deleting an image would
do anything significant...
Dirk Wenke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ed,
I am now able to reproduce the OutOfMemory problem.
I start my eclipse and after initialisation it occupies around 50MB. Then
I delete 3 images that are contained in one of my plugins => eclipse
starts a build of the workspace and runs out of memory (with -Xmx512m). I
profiled this with JProfiler and saw, that most of the space is used for
char[] objects (376MB) and ClassPathAccessRule objects (74MB).
But I think that information does not help very much. Is there anything
else I can do? The problem is, that I cannot give away my workspace,
because I can't give away the source code of our major products.
Best,
Dirk
----
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn9pa3$2pt$1@build.eclipse.org">news:fn9pa3$2pt$1@build.eclipse.org</a>...
Dirk,
If you can package up the problem in a reproducible way it would make a
great bugzilla report. I.e., a workspace for which repeated changes to
some file or set of files will gradually consume the heap would be enough
for someone else to see the problem. It might well be something special
about a particular Java construct you have in some file. Who knows. I
assume you've been monitoring the Error log for signs of distress before
things start to go wrong. Of course if you could run your scenario using
some kind of heap analysis tool to determine which types of objects are
leaking, that would be a big asset too and would likely help point toward
what component was producing all the leaked information.
Of course I would be tempted to install the latest maintenance stream of
whatever version of Eclipse you are using and install in it only the base
platform SDK and try to reproduce the problem that way. Then I'd
gradually add any other plugins to the installation until the problem
starts to manifest again...
Dirk Wenke wrote:
Hi Ed,
I removed all builders from our projects except for the JavaBuilder,
ManifestBuilder and SchemaBuilder.
But eclipse is unfortunatly still running out of memory :(
This morning I started eclipse (occupied 50-70MB after initialization),
synchronized with our CVS (I did not update anything, just wanted to
commit
some changes) and while commiting the resources, eclipse started a
workspace
build and within a minute the complete heap space was in use and eclipse
ran
out of memory.
Currently I run eclipse with the following options
-vmargs
-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=512m
I decreased the max heap size and increased the size of the permanent
generation space. But that did as well not solve the problem.
Do you have any other suggestions?
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn7suv$lg3$2@build.eclipse.org">news:fn7suv$lg3$2@build.eclipse.org</a>...
Dirk,
I'm just trying to help narrow the issue down so you can get it to the
stage of reproducibility and then open a bugzilla. Because I've never
see
a problem like this with almost 200 plugins in my workspace, I'd be
suspicious of that style checker thing you have. Perhaps you might
disable that plugin and see if the problem persists.
Dirk Wenke wrote:
Hi Ed,
I know that the little heap monitor has a button to force garbage
collection. But the garbage collection does not solve the Problem. The GC
does not seem to find many objects to destroy. So if the used memory is
near the max heap size and I force garbage collection, sth. between 30-50
MB are released, but that's not much, if nearly 1000 MB are in use... So
explicitly forcing garbage collection does not prevent eclipse from
running out of memory.
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn76cg$98j$1@build.eclipse.org">news:fn76cg$98j$1@build.eclipse.org</a>...
Dirk,
I see that now. Your problem does seem to be indicative of a bug
somewhere though. So you're saying that your heap isn't gradually
growing over time based on other activities (opening and closing
editors), but rather that some particular build kicks in that consumes a
lot of memory and after that the memory is not released, so the next
build is a bit worse, and so on until there's no space? But you're not
sure what causes this to happen because things are going fine for quite a
while first? And your not sure what change/activity first starts to
cause the heap to begin using more memory and not releasing it? I think
that little control can let you for a collection to happen...
Dirk Wenke wrote:
Hi Ed,
I am not saying that this is a bug in eclipse, otherwise I would have
written a bug report. But I need somehow to find out what is causing this
problem. Or at least how to avoid my eclipse running out of memory. This
is
why I writing to the newsgroups.
We are already monitoring the heap status, which I wrote in my first
message:
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
This problem always occurs while building the workspace, never while
running
the runtime workbench or doing sth. else.
Even if I am running eclipse with -Xmx1024M heap size it still happens
that
during the build of the workspace the used heap rapidly grows from 150MB
up
to 1000MB and then sometimes throws an OutOfMemory error. But even if
eclipse is not running out of memory, only parts of the heap allocated
during the workspace build is released.
The strange thing is that we are developing with eclipse 3.2.1 since more
than 1,5 years and this problem occured the first time 4 months ago. But
we
were not able to find out what change might be the cause of the problem.
We
removed all new plugins from our workspace, because we thought that one
of
our newer plugins is the cause for this problem, but eclipse still ran
out
of memory. So at this point we are really lost.
Best,
Dirk
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn704q$ggg$1@build.eclipse.org">news:fn704q$ggg$1@build.eclipse.org</a>...
Dirk,
In this case your heap is only -Xmx512M. I have about 180 plugins in my
workspace including all of EMF, GMF, GEF, UML, XSD, and so on. I've
never
run out of heap space. You might want to use
"Window->Preferences->General->Show heap status" and monitor the heap's
growth as you use the workspace. It seems more likely that you might
have
an editor that's leaking than that the build itself is leaking the
memory.
The problem with memory exhaustion is that one tends to blame the straw
that
broke the camel's back because it's the most obvious, but it might not be
the cause for the accumulation of rest of the straw...
Dirk Wenke wrote:
Hi Eric,
thanks for your help. But it does not look like a PermGen space problem.
We
already tried to solve the problem by setting the maxPermSize, but that
did
not work.
The exception logged to the eclipse .log looks like the following:
!ENTRY org.eclipse.ui 4 0 2007-12-04 09:27:45.359
!MESSAGE Java heap space
!STACK 0
java.lang.OutOfMemoryError: Java heap space
at org.eclipse.jdt.internal.core.builder.State.readName(State.j ava:315)
at
org.eclipse.jdt.internal.core.builder.State.readRestriction( State.java:334)
at org.eclipse.jdt.internal.core.builder.State.read(State.java: 255)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.readState( JavaBuilder.java:146)
at
org.eclipse.jdt.internal.core.JavaModelManager.readState(Jav aModelManager.java:2596)
at
org.eclipse.jdt.internal.core.JavaModelManager.getLastBuiltS tate(JavaModelManager.java:1371)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.getLastSta te(JavaBuilder.java:391)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:171)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:603)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:167)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:233)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop (BuildManager.java:252)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:285)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu ildJob.java:145)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJ ob.java:208)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
!SESSION 2007-12-04
09:28:52.562 -----------------------------------------------
eclipse.buildId=M20060921-0945
java.version=1.5.0_10
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -Xmx512M
Command-line arguments: -os win32 -ws win32 -arch x86 -Xmx512M
Any other comments welcome :)
Best,
Dirk
"Eric Rizzo" <a class="moz-txt-link-rfc2396E" href="mailto:eclipse-news@rizzoweb.com"><eclipse-news@rizzoweb.com></a> schrieb im Newsbeitrag
<a class="moz-txt-link-freetext" href="news:fn58dv$661$3@build.eclipse.org">news:fn58dv$661$3@build.eclipse.org</a>...
Dirk Wenke wrote:
Hi,
I currently have a problem with my eclipse running OutOfMemory while
building the workspace.
I am running eclipse3.2.1(Build id: M20060921-0945) with EMF and GEF with
JDK1.5.
In the workspace we have something about 60 additionally plugins we are
developing.
This is a really strange problem, because it is not reproducible at all.
You can work with eclipse for a week without any problems and on the next
day it runs out of memory every half an hour. The problem only occurs
while building the workspace.
It seems like there exists some kind of memory leak. Initially we ran
eclipse with -Xmx256m and after these problems we increased the maximum
heap size up to 1GB, but eclipse is still running out of memory. In the
preferences we enabled the display of the heap status: Normally eclipse
occupies something between 100MB to 150MB but sometimes it occupies more
and more memory while building the workspace without releasing any memory
that is no longer needed.
I already tried it with a completely new eclipse installation and a new
workspace, but the problem still occurs.
Is this a known problem? Or may this be caused by an external library we
are using?
Look carefully at the .log messages when this happens - I'll bet it is
actually a PermGen space error, not a heap space problem.
If so, you'll need to set the max PermGen size in your eclipse.ini -
Google for how to do that, it is a much-discussed topic (the default
PermGen size on Sun JVMs is, unfortunately, very small).
Hope this helps,
Eric
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------060202030303000301060003--
|
|
|
| Re: eclipse 3.2.1 running OutOfMemory while building workspace [message #251181 is a reply to message #251157] |
Fri, 01 February 2008 08:18 |
| Eclipse User |
|
|
|
On Thu, 31 Jan 2008 16:17:45 +0100, Dirk Wenke wrote:
> Hi Ed,
>
> I think we found the cause of the problem.
> We started eclipse with -XX:+HeapDumpOnOutOfMemoryError and analyzed the
> heap dump afterwards with the memory analyzer provided by SAP.
> Nearly all heap space is allocated by a HashMap in the JavaModelManager.
> Taking a deeper look at this HashMap, we found out that most of the space is
> needed for org.eclipse.jdt.internal.compiler.env.AccessRule arrays.
> The really strange thing is, that many of these arrays exist but nearly all
> having the same size and containing the same elements. This looks like a bug
> to me.
Hi Dirk. Please open a bug against JDT Core with as many details as you
can on your setup. As Ed writes in his answer, this is more likely a
usage scenario that we did not expect than a bug affecting anticipated
scenarios, but we should have a sharp look at it. It might well be that we
need much more aggressive sharing of access rules than we figured
out initially.
Thx for your help.
Maxime
|
|
|
Goto Forum:
Current Time: Sun Apr 20 19:43:08 EDT 2025
Powered by FUDForum. Page generated in 0.05631 seconds |
Home