Community
Participate
Working Groups
Build ID: Version: 3.2.1 Build id: M20060921-0945 Steps To Reproduce: 1. create a plugin project that contains JUnit test cases. The test cases will a. create a java project in the launched workspace, b. populate the project with application level junit java code, c. build the generated project, and d. execute the generated junit code. 2. execute the test case using Run As JUnit Plug-in Test 3. Repeat step 2 until you see the error My project is quite large at the moment. I'll try to trim it down to something I can post. I'm not the only one seeing OOME in java indexer. See also the blog at http://www.adam-bien.com/roller/page/abien/20060801 More information: !ENTRY org.eclipse.jdt.core 4 4 2006-11-29 09:04:24.546 !MESSAGE Background Indexer Crash Recovery !STACK 0 java.lang.OutOfMemoryError: Java heap space
Since I have a project that seems to cause the problem fairly consistently, I will be happy to do a little debug on this if someone can point me to the correct project. Which eclipse project do I need to pull from CVS to debug this, and what module should I start looking at? Are there any debug options (.options file) that I can set to collect more info about what might be going on? Michael
Would it be possible to zip and attach the plugin project with JUnit test cases to run? Do you delete the workspace while running your launch config of these test cases? If you do not delete it, can you make a try checking this box in your launch config ('Main' tab)? Have you try to increase the Java Heap size while running your tests? If not please make it while adding at least -Xmx512M in VM arguments ('Arguments' tab) of your launch config and more if your box has enough memory... You can activate debug trace while running your test cases. For this, in the launch config, select the 'Tracing' tab and check 'Enable tracing for the selected plugins' box. In the plugins list, check org.eclipse.jdt.core box and debug/indexmanager in the list of debug constants in the right panel... Run your tests, put the console outputs in a file and attach the file to this bug, thanks
Another question, do you have any other plugins installed on top of eclipse SDK? If so, can you make a try with a fresh install of eclipse?
(In reply to comment #2) > Would it be possible to zip and attach the plugin project with JUnit > test cases to run? Unfortunately, the plugin project is the test driver for a collection of plugins we have developed. I could send you the junit project, but without the rest of the plugins that it is testing, it will not build or run. > Do you delete the workspace while running your launch config of these test > cases? Yes. > If you do not delete it, can you make a try checking this box in your launch > config ('Main' tab)? We have tried reusing the workspace, and also deleting it. Either approach fails. > Have you try to increase the Java Heap size while running your tests? If not > please make it while adding at least -Xmx512M in VM arguments ('Arguments' > tab) of your launch config and more if your box has enough memory... I have not been setting these options in the launch. These are set in the eclipse.ini file. The launch is initiated programmatically, so I'll have to modify my code to make these changes. QUESTION: does the eclipse.ini file apply to launches? > You can activate debug trace while running your test cases. For this, in the > launch config, select the 'Tracing' tab and check 'Enable tracing for the > selected plugins' box. In the plugins list, check org.eclipse.jdt.core box and > debug/indexmanager in the list of debug constants in the right panel... > Run your tests, put the console outputs in a file and attach the file to this > bug, thanks Launch is initiated programmatically. I'll modify the code to add this. I'll post results.
(In reply to comment #3) > Another question, do you have any other plugins installed on top of eclipse > SDK? If so, can you make a try with a fresh install of eclipse? I have lots of other plugins installed, but since these are the target of the junit plugin testing, it is not possible to remove them.
(In reply to comment #2) > Have you try to increase the Java Heap size while running your tests? If not > please make it while adding at least -Xmx512M in VM arguments ('Arguments' > tab) of your launch config and more if your box has enough memory... I added -Xmx512m -XX:MaxPermSize=640m to the vmargs for the launch and have run several tests successfully. This appears to have resolved the issue. So it seems my question is answered, the launch does not use the options from eclipse.ini file. This combined with the fact the Eclipse 3.2 requires a large MaxPermSize in general, it seems this is a bug for the platform. I would like to see you transfer this bug to the platform team and recommend that they figure out a way to enforce a larger MaxPermSize and larger -Xmx for all launches. The defaults for this should be platform wide, and apply to all launches. Otherwise, every bit of code that initiates a launch will have to include these params to be successful.
(In reply to comment #6) > > I added -Xmx512m -XX:MaxPermSize=640m to the vmargs for the launch and have > run several tests successfully. This appears to have resolved the issue. > Great. > So it seems my question is answered, the launch does not use the options from > eclipse.ini file. This combined with the fact the Eclipse 3.2 requires a > large MaxPermSize in general, it seems this is a bug for the platform. > > I would like to see you transfer this bug to the platform team and recommend > that they figure out a way to enforce a larger MaxPermSize and larger -Xmx for > all launches. The defaults for this should be platform wide, and apply to all > launches. Otherwise, every bit of code that initiates a launch will have to > include these params to be successful. > I do not think that launch configuration default should be changed. The default should be to use the VM default value => do not specify any arguments. Usually JUnit test does not consume too much memory, it sounds normal not to specify same VM arguments than eclipse ones. If some tests needs specific amount of memory then user who knows that should change the default values using the interface. IMO, this behavior sounds to be the correct one... Move to JDT/Debug who owns launch configurations to decide what to do about this request...
PDE owns the JUnit plug-in launcher.
(In reply to comment #7) > I do not think that launch configuration default should be changed. The default > should be to use the VM default value => do not specify any arguments. I cannot agree. From a user perspective, the VM defaults are those set when I launched Eclipse. If I need to specify -Xmx and -XX:MaxPermSize to make the primary workbench run correctly, then it is reasonable to expect the same parameters are needed in a launch, especially a junit plugin launch that is attempting to automate tests for the same environment. The user has specified vm args in eclipse.ini, or on the command line when eclipse was started. In my specific case, I specified these values in eclipse.ini and I think I have a reasonable expectation that these values will be used for all launches as well. > Usually > JUnit test does not consume too much memory, it sounds normal not to specify > same VM arguments than eclipse ones. This might be true for a simple application junit launch, but for junit plugin test, the launch will need the same resources as the launching environment. > If some tests needs specific amount of > memory then user who knows that should change the default values using the > interface. IMO, this behavior sounds to be the correct one... IMO, if the user has set memory requirements in eclipse.ini, then these should be applied to all eclipse launches. > Move to JDT/Debug who owns launch configurations to decide what to do about > this request... Thanks.
reassigning to me and changing the name of this bug
Created attachment 58237 [details] org.eclipse.pde.ui.patch initial stab, a bit tired tonight :)
if you have time Brian, can you review this for sanity? I'm not sure there's really a better way to do this, seems a bit fragile for me though.
made some optimization changes, committed to head
*** Bug 169632 has been marked as a duplicate of this bug. ***
I agree with comment 7. Making the target settings match the dev settings by default is a bad idea. See bug 176175.
(In reply to comment #15) > I agree with comment 7. Making the target settings match the dev settings by > default is a bad idea. See bug 176175. I think that bug 176175 suggests a checkbox that enables or disables the use of eclipse.ini file. This seems reasonable as long as there is a method on ILaunchConfiguration to enable/disable the use of eclipse.ini settings. Of course my preference is that the default is to use the settings from eclipse.ini. The thinking here being that a person has a reasonable expectation that eclipse.ini applies to all launches of eclipse regardless of how the instance was started. eclipse.ini should not be limited to launches initiated from the command-line (imo).
I am backing out this change for M6 as it made people angry. will come up with a configurable solution for M7.
as per the resolution of bug 176175, we added a global checkbox to the Plug-in Development > Target Platform > Launching arguments preference page to specify if vmargs from the target's launcher ini file should be added to newly created launch configurations. By default, it is unchecked, since that is the default behavior since the beginning of time. If checked, PDE puts the vmargs directly into the launch configs so that the user is aware of them and modify them (bug 173883). We do not implicitly append anything upon launching. PDE is getting completely out of the middle. We want to have a peaceful summer.
This sounds like a reasonable approach. I'll be sure to check it out when I pull M7.
*** Bug 180477 has been marked as a duplicate of this bug. ***
*** Bug 208936 has been marked as a duplicate of this bug. ***
*** Bug 209065 has been marked as a duplicate of this bug. ***
>By default, it is unchecked, since that is the default behavior since the >beginning of time. As I have received 3 bugs this week about about of memory errors self hosting I think this should be on by default. Having your launch inconsistent with your working environment doesn't seem like expected baehaviour to me - note the amount of dups this has.
(In reply to comment #23) > >By default, it is unchecked, since that is the default behavior since the > >beginning of time. > I think this should be on by default. Having your launch inconsistent with your > working environment doesn't seem like expected baehaviour to me - note the > amount of dups this has. +1 As the original submitter, I will be very happy to see the default set to ON :-)
See Bug 209347 for a request to change this,
*** Bug 221769 has been marked as a duplicate of this bug. ***
