Community
Participate
Working Groups
Build Identifier: 20110615-0604 I use a larger update-site with 8 categories, 60 features included. For historical reasons I use a standard Eclipse-update-site-project from the UI. Pressing "Build all" runs the build. "Generating ant scripts" seems to work but the build crashes with OutOfMemoryError, "no more handles" or can't create native thread. No plan about the dependencies. The same project runs fine with Helios. The used Indigo workspace was created from the scratch: created a new one and checked out all projects from the SVN repository. I tried already closing all perspectives keeping only the open editor with "site.xml" and restarting the workbench with this open editor area without any other view or perspective. But no luck. Reproducible: Always
Created attachment 198873 [details] The workbench log file Added the workbench log file from the crashed update-site build.
It won't be PDE Build causing the out of handles exception (though it could be causing the OOM as I have seen other problems doing export operations). I don't have the time to try tracking down a possible handles leak in the site editor.
The problem occurs with other export actions to: Exporting a smaller RCP application I got the same problem: !ENTRY org.eclipse.core.jobs 4 2 2011-07-06 13:08:25.050 !MESSAGE An internal error occurred during: "Export Product". !STACK 0 java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Unknown Source) at java.util.zip.ZipFile.getInflater(Unknown Source) at java.util.zip.ZipFile.getInputStream(Unknown Source) at java.util.zip.ZipFile.getInputStream(Unknown Source) at java.util.jar.JarFile.hasClassPathAttribute(Unknown Source) at java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Unknown Source) at sun.misc.URLClassPath$JarLoader.getClassPath(Unknown Source) at sun.misc.URLClassPath.getLoader(Unknown Source) at sun.misc.URLClassPath.getResource(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at org.eclipse.ant.internal.core.AntClassLoader.findClass(AntClassLoader.java:54) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.ant.core.AntRunner.getInternalAntRunner(AntRunner.java:398) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:323) at org.eclipse.pde.internal.core.exports.FeatureExportOperation.cleanup(FeatureExportOperation.java:851) at org.eclipse.pde.internal.core.exports.ProductExportOperation.run(ProductExportOperation.java:124) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Same error in eclipse 3.7, exporting RCP Application LOG: !ENTRY org.eclipse.core.jobs 4 2 2011-08-23 14:51:26.100 !MESSAGE An internal error occurred during: "Export Product". !STACK 0 java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Unknown Source) at java.util.zip.ZipFile.getInflater(Unknown Source) at java.util.zip.ZipFile.getInputStream(Unknown Source) at java.util.zip.ZipFile.getInputStream(Unknown Source) at java.util.jar.JarFile.hasClassPathAttribute(Unknown Source) at java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Unknown Source) at sun.misc.URLClassPath$JarLoader.getClassPath(Unknown Source) at sun.misc.URLClassPath.getLoader(Unknown Source) at sun.misc.URLClassPath.getResource(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at org.eclipse.ant.internal.core.AntClassLoader.findClass(AntClassLoader.java:54) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.ant.core.AntRunner.getInternalAntRunner(AntRunner.java:398) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:323) at org.eclipse.pde.internal.core.exports.FeatureExportOperation.cleanup(FeatureExportOperation.java:851) at org.eclipse.pde.internal.core.exports.ProductExportOperation.run(ProductExportOperation.java:124) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
The change garbage collector to -XX:+UseConcMarkSweepGC avoid the problem. See http://bugs.sun.com/view_bug.do?bug_id=4797189
(In reply to comment #5) > The change garbage collector to -XX:+UseConcMarkSweepGC avoid the problem. > See http://bugs.sun.com/view_bug.do?bug_id=4797189 Unfortunatly this option doesn't solve my problem: I get: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Unknown Source) at java.util.Timer.<init>(Unknown Source) at java.util.Timer.<init>(Unknown Source) at org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool.<init>(DefaultSVNRepositoryPool.java:146) at org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool.<init>(DefaultSVNRepositoryPool.java:121) at org.tmatesoft.svn.core.javahl.SVNClientImpl.getClientManager(SVNClientImpl.java:1861) at org.tmatesoft.svn.core.javahl.SVNClientImpl.getSVNUpdateClient(SVNClientImpl.java:1873) at org.tmatesoft.svn.core.client.SVNClientEx.setTouchUnresolved(SVNClientEx.java:40) at org.tmatesoft.svn.core.client.SVNClientEx.<init>(SVNClientEx.java:35) at org.polarion.team.svn.connector.svnkit.SVNKitConnector.<init>(SVNKitConnector.java:93) at org.polarion.team.svn.connector.svnkit.SVNKitConnectorFactory.newInstance(SVNKitConnectorFactory.java:32) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifierFactory.newInstance(ThreadNameModifierFactory.java:57) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.getStatuses(SVNRemoteStorage.java:863) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.loadLocalResourcesSubTreeSVNImpl(SVNRemoteStorage.java:781) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.loadLocalResourcesSubTree(SVNRemoteStorage.java:660) at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.asLocalResource(SVNRemoteStorage.java:424) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.getSyncInfo(AbstractSVNSubscriber.java:138) at org.eclipse.team.core.subscribers.Subscriber.getDiff(Subscriber.java:371) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager.getDiff(SubscriberChangeSetManager.java:302) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager$EventHandler.handleChange(SubscriberChangeSetManager.java:183) at org.eclipse.team.internal.core.subscribers.SubscriberChangeSetManager$EventHandler.doDispatchEvents(SubscriberChangeSetManager.java:80) at org.eclipse.team.internal.core.BackgroundEventHandler.dispatchEvents(BackgroundEventHandler.java:394) at org.eclipse.team.internal.core.BackgroundEventHandler.processEvents(BackgroundEventHandler.java:374) at org.eclipse.team.internal.core.BackgroundEventHandler$1.run(BackgroundEventHandler.java:203) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) But it seems to be unpredictible, which thread gets the OutOfMemoryError or an "No more handles" or an "Can't create native thread" error?
(In reply to comment #6) > Unfortunatly this option doesn't solve my problem: -XX:+UseConcMarkSweepGC Is not a Key option, Key option is '-Xmx512m'. Reduce available memory to JVM! Strange but true. Exactly my eclipse.ini (-Xmx512m - Primary key option.) --- -startup plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20110502 -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile -vmargs -Xmn256m -Xms512m -Xmx512m --- My environment is: java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 20.2-b06, mixed mode, sharing) Eclipse SDK Version: 3.7.0 Build id: I20110613-1736
(In reply to comment #7) Thanks for the proposal. In my system I can't recognize any change in the misbehaviour :(
Not absolutely sure that this is a dupe of bug 346730, but the out of memory exceptions appear to be related. *** This bug has been marked as a duplicate of bug 346730 ***
