Community
Participate
Working Groups
Build Identifier: 3.6.x I20100608-0911 In case you have a very huge classpath and also many VM arguments for your junit test suite, you are not able to run it inside eclipse. The internal builded command line for the RemoteTestRunner process gets too long and reaches the windows xp limit (8191 characters). The error you get looks like this: Pop up "Problem occured" with Message: Exception occurred executing command line. Cannot run program "C:\Apps\Tip60\cs\java\jdk160_16\bin\javaw.exe" (in directory "C:\DevWork\Projects\Frontnet\rmt.head\RMT\lib\RMT"): CreateProcess error=87, The parameter is incorrect Stack Trace from Error Log: java.io.IOException: Cannot run program "C:\Apps\Tip60\cs\java\jdk160_16\bin\javaw.exe" (in directory "C:\DevWork\Projects\Frontnet\rmt.head\RMT\lib\RMT"): CreateProcess error=87, The parameter is incorrect at java.lang.ProcessBuilder.start(Unknown Source) at java.lang.Runtime.exec(Unknown Source) at org.eclipse.debug.core.DebugPlugin.exec(DebugPlugin.java:827) at org.eclipse.jdt.launching.AbstractVMRunner.exec(AbstractVMRunner.java:73) at org.eclipse.jdt.internal.launching.StandardVMRunner.run(StandardVMRunner.java:317) at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.launch(JUnitLaunchConfigurationDelegate.java:174) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:853) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:923) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1126) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.io.IOException: CreateProcess error=87, The parameter is incorrect at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.<init>(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source) ... 11 more There exist currently no workaround to solve that issue. You need to rewrite your testsuite e.g. by using ant inorder to shorten the command line by uisng a "proxy" process which has an own class loader andconfiguration loader. Expectation: - extend the Junit Runner, add a configuration option for passing over an own classpath which uses a java class loader before the test starts. - don't use the command line to pass over the classpath or configuration (syste m properties) - Please have a look at the IDE "Idea" there they are using also an own runner, but the classpath configuration is not passed via a command line refer also to: http://www.eclipse.org/forums/index.php?t=msg&th=197955 http://support.microsoft.com/kb/830473 many thanks in advance. regards Mark Reproducible: Always Steps to Reproduce: 1. create one single project with many jar files in the classpath. The path for each jar file should be long. The overall string for the full class path should approx. exceeds 8100 characters 2. write a junit test for that project 3. setting up a junt run configuration and some VM arguments. Use as classpath the path of the project. If necessary add the Junit library additionally to the classpath 4. try to run the junit test.
Hi, I have exactly the same problem. Same popup error and same massage in log file. Is there any solutions or tricks to solve this problems ? Thanks very much Loïc
I guess you run into the same problem with a normal Java Application launch configuration. Moving to Debug for a general solution. I looked around a bit, and I found only one solution apart from implementing a special class loader: Replace the arguments to -classpath with a single reference to a generated JAR with a MANIFEST.MF whose Class-Path attribute is set to the long class path. http://stackoverflow.com/questions/201816/how-to-set-a-long-java-classpath-in-msdos-windows http://www.java.net/forum/topic/javadesktop/general-desktop-discussions/general-desktop-issues-discussion/launching-jav-0
Overall, it would be nice if: * I could add a jar directory instead of having to select the jars I want to add. * My buildsystem could add a single entry in .classpath for the whole directory. * When this happened, Eclipse would use the * notation added in Java 1.6, or one of the other solutions suggested here.
This also happens to me when I try to launch a large maven project. I use m2e plugin and maven dependencies. IMO, the Eclipse launcher should generate classpath.jar on windows if classpath too long.
It is true the issue is not only related to the internal JUnit runner, the same issue appears also when you are using the internal java application runner. However I solved the issue for me by using an own class loader which reads the ".classpath" files of my project at runtime. (Refer to the attachment as an example). In my launch configuration I simple added via the VM arguments this custom classloader and in the classpath settings I removed all the entries except the one to my class loader. As working directory I simple set the project directory, in order to ensure that the classpath file get found. Hope this helps for the ones which are struggling over this issue and need an urgent solution without repackaging everytime a huge jar file etc. I still hope that the current runners from eclipse get improved, means they should use a kind of wrapper with a special class loader which you can specify, overwrite when necessary. The classpaths in the future will get longer and longer, so there is stongly a need for it! Thank you regards Mark
Created attachment 202740 [details] special class loader which reads the .classpath file at runtime for resolving the classpath use this class laoder at runtime in your launch configuration. Use it by adding the following JVM argument in your launch settings: -Djava.system.class.loader=EclipseProjectClassLoader
Created attachment 202834 [details] patch for long classpath on windows There's an array 'String[] cp' that holds the classpath for the debugee. Currently, all entries from it are added to the command line argument '-classpath'. This patch does the following: If we're on Windows and the command line appears to be too long, it reads the classpath array again, but this time all entries that look like absolute .jar paths are added to the manifest of the generated classpath.jar instead of the command line. classpath.jar itself is added to the command line.
In IntelliJ IDEA they substitute the main class with a generated one. It contains the hardcoded classpath and the code to launch the original main class.
Comment on attachment 202834 [details] patch for long classpath on windows Apparently, GWT DevMode doesn't work when it's jars are listed in manifest file and not in URLClassLoader
Created attachment 205716 [details] patch for long classpath on windows Hi, it's me, leniviy. This time I substituted the main class, just like in Idea. My class reads urls from a text file and uses the well-known way to add urls to URLClassLoader. I wanted to embed urls into the class itself, but I don't know how to use eclipse java compiler in other plugins.
Bug #256584 is a duplicate of this. Also, this line issue is seen on Windows 7 too.
*** This bug has been marked as a duplicate of bug 256584 ***
Ah! wanted to mark 256584 a dupe of this one...
*** Bug 256584 has been marked as a duplicate of this bug. ***
I uswe m2Eclipse so not able to use any of the patches. I am trying to get a view of the offending commandline. I cant seem to do this at all. I have shortened the m2 repo directory to m2 so cant make the commandline much smaller. I need to see what is being sent to the commandline so I can work out if I can take any bits out. I cant use the Window -> Show View -> Debug -> Debug Properties method to show the launch commandline as the application is not launching. I would like to be able to see the commandline that was used and caused this issue. Does anybody have any advice on how I can do this. Thanks.
(In reply to comment #15) > I uswe m2Eclipse so not able to use any of the patches. Why you think so? We're using m2eclipse with my patch. I would put here a fixed jar file, but each version of eclipse has it's own org.eclipse.jdt.launching jar
(In reply to comment #15) Hi George > I uswe m2Eclipse so not able to use any of the patches. I think you sould also be able to use my example classloader in case you liek to run it inside eclipse for testing purposes. Let me know why this does not work for you. > I am trying to get a view of the offending commandline. I cant seem to do this > at all. I have shortened the m2 repo directory to m2 so cant make the > commandline much smaller. I need to see what is being sent to the commandline > so I can work out if I can take any bits out. > I cant use the Window -> Show View -> Debug -> Debug Properties method to show > the launch commandline as the application is not launching. > I would like to be able to see the commandline that was used and caused this > issue. > Does anybody have any advice on how I can do this. > Thanks. You can use a third party tool from systeminternals (now Microsoft) called "ProcessExplorer". regards Mark
(In reply to comment #17) Mark Thanks for the response. I did not fully understand the point at which your patch kicked in and thought it was merely to do with normal luanches rather than any launch no matter how the commandline is constructed. It would be nice to see this patch accepted and pulled into the main code. I tried using ProcessExplorer as you suggested but the actually process dies before ever appearing in the explorer I have. I downloaded the very latest version, v15.13 (http://technet.microsoft.com/en-us/sysinternals/bb896653) in the hope I could get some further info. In addition to this issue it seems an ommision from eclipse that I am unable to log or switch on logging that will enable the commandline being used to run the application to be output to a log or the console. I have checked the bug list etc and can find no request for this. I know I can see the commandline in the Debug properties, but as I cant run up the process I have no access to this. Should I raise a feature request to enable this, or is anybody aware of how I can get the commandline being used to start an application. I have read posts on other sites requesting this as some people want to use this to launch their app outside of eclipse, so it is not merely useful in the case when the java process dies as in this bug, but there are other use cases for this information.
(In reply to comment #18) Hi Georg There is no real patch yet available nor an release planing by when it will be done. You find in this discussion only some examples and suggestions how you can do it on your own. Which one of these is applicable depends on your situation. The bug here describes that the junit or java launcher can not be used in case the classpath or command line arguments exceed the limitation of the operating system. To solve that problem outside of eclipse is a total different story and should be disucssed on another platform (stack overflow or whatever). Your post is about two issues, one is how to find out the generated commandline and the other one is how to get the process running inside eclipse. To find out how the command line gets generated, I suggest the follwoing: 1. make a sample project according to yours but one which works (reduce it to the max) 2. start the application in debug mode, if you can not attach the debugger modify the jvm arguments so you have first to connect the debugger e.g. -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7570 3. while the application is waiting use a third party tool as the process explorer to investigate the process details. To get your application inside eclipse running, you need to reduce the command line. As mentioned there are different strategies. You need to find out which one is the best for you: - reduce the classpath - use directories instead of jar files - use a packed jar files which contains all other jars, use the classpath variable inside the manifest file to point to the other jars - use a special class loader which reads the classpath from a config file - try to use onw of the attached patches here - use an own wrapper e.g. ant Hope this helps, good luck! regards Mark
*** Bug 376393 has been marked as a duplicate of this bug. ***
'GWT compile project' tool from GWT plugin for Eclipse 3.6 successfully uses CLASSPATH env var instead of -classpath. It works in my project with classpath length 48000 on windows 7.
In searching the internet looking for a fix to Bug 376393 I saw that it was considered a duplicate of this bug. This bug has been active since 2010. I thought I would give some information regarding this bugs impact on the use of the Eclipse product as I am a faithful Eclipse user. This bug has caused the entire engineering department at Expedia.com (approax. 200 devs) to move to a paid product, IDEA intellij, due to their inability to use the IDE for debugging or running JUnits. I can only imagine this is happening elsewhere as well. Hopefully you can get this fixed and into the next version of Eclipse. The exact error is on windows boxes and as follows: Exception occurred executing command line. Cannot run program "C:\Program Files\Java\jre6\bin\javaw.exe" (in directory "D:\src\expweb\expweb\trunk"): CreateProcess error=206, The filename or extension is too long Hopefully this information is helpful.
(In reply to comment #21) The CLASSPATH environment variable sounds like the best solution. Once bug 285720 is fixed, this also allows the user to see the classpath even if it's longer than what the OS can manage. Mike, could you put this on the 4.3 plan? (In reply to comment #22) Thanks for your input. > This bug has caused the > entire engineering department at Expedia.com (approax. 200 devs) to move to a > paid product Sad to hear, but if that's true and that was their main reason, then the managers and/or devs are not worth their money.
As an employee for expedia.com, I can say that we support both Eclipse and IntelliJ and we currently have developers using both. Some developers have switched to IntelliJ and this bug was a contributing factor. I use and prefer IntelliJ for several reasons, and have been using it since before we knew about this issue.
> Mike, could you put this on the 4.3 plan? I thought I had already, I guess I forgot when I tagged it as having a patch.
I work on a product that has > 100 plugins (and quite a few 3rd party jars) and we experience this as well in plugins that are further down the hierarchy (and thus have longer class paths). It is really quite annoying as it effectively prevents one from running/writing plain JUnit tests (or any classes with main() methods). As a side note: Plugin-Tests work, but there's really no point in starting the whole environment if a simple, plain JUnit test can do the trick. Could, that is. Please solve this, I'm sure we (and the ones at Expedia.com) are not the only ones experiencing this problem.
PS: We're using 3.7 INDIGO, switching to 4.3 is not really an option at the moment, so resolve for 3.8 (or a fix for 3.7) would be more than welcome.
(In reply to comment #27) > PS: We're using 3.7 INDIGO, switching to 4.3 is not really an option at the > moment, so resolve for 3.8 (or a fix for 3.7) would be more than welcome. What's the exact name of your plugins/org.eclipse.jdt.launching_*.jar ?
(In reply to comment #28) > What's the exact name of your plugins/org.eclipse.jdt.launching_*.jar ? org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar
Created attachment 216593 [details] replace files in org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar (In reply to comment #29) > (In reply to comment #28) > > What's the exact name of your plugins/org.eclipse.jdt.launching_*.jar ? > > org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar take class files in attached zip and replace files in your jar. Then start eclipse once with -clean option
(In reply to comment #30) > take class files in attached zip and replace files in your jar. Then start > eclipse once with -clean option Thank you! Works like a Charm. :D
(In reply to comment #30) > Created attachment 216593 [details] > replace files in org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar > > (In reply to comment #29) > > (In reply to comment #28) > > > What's the exact name of your plugins/org.eclipse.jdt.launching_*.jar ? > > > > org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar > > take class files in attached zip and replace files in your jar. Then start > eclipse once with -clean option will it work for org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar?
Created attachment 216637 [details] org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar (In reply to comment #32) > will it work for org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar?
(In reply to comment #33) > Created attachment 216637 [details] > org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar > > (In reply to comment #32) > > will it work for org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar? Works fine!
I'm suprised: the problem is existing on Juno too (Build id : 20120606-2254) How come org.eclipse.jdt.launching_3.6.100.v20120523-1953 doesn't include the patch?
(In reply to comment #35) > How come org.eclipse.jdt.launching_3.6.100.v20120523-1953 doesn't include the > patch? There is no approved patch attached to this bug. See comment 23 for the way to implement this.
Ilya Basin attached patched jar that correct the problem.
seems to be a better idea to patch a 3.5.* version than to use org.eclipse.jdt.launching_3.5.200.v20110105_r362.jar So just go ahead and patch it like this. jar.exe uf org.eclipse.jdt.launching_3.5.100.v20100526.jar org/* P.s. For the record i am using Win7 PRO 64bit and had that problem.
(In reply to comment #10) > Created attachment 205716 [details] > patch for long classpath on windows > > Hi, it's me, leniviy. > This time I substituted the main class, just like in Idea. > My class reads urls from a text file and uses the well-known way to add urls to > URLClassLoader. The patch works fine for me, a few things: 1. the code needs to be updated to use generics to get rid of the 'raw type' warnings 2. we should propagate the file encoding specified in the runner to the streams used in shortenCommandLine(..) 3. in shortenCommandLine there is a comparison of the command length to 30000, which seems arbitrary to me, from the MS article the overall length can't exceed 8191 chars, so shouldn't we compare the complete command to that + if the OS is Windows? If so then augment the classpath (as needed). 4. the process properties page does not show all of the libraries used during the launch, instead you see the modified command with the classpath file name + new main, etc For example I launched a Java app with a few thousand jars on the classpath and see this in the commandline text: "C:\Program Files\Java\jre7\bin\javaw.exe" -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:53487 -Dmy.arg=BAR -Dfile.encoding=Cp1252 -classpath C:\Users\mrennie\AppData\Local\Temp\eclipse5824704610217828960tmp org/eclipse/jdt/internal/launching/LongCommandLineLauncher C:\Users\mrennie\AppData\Local\Temp\urls699514321351953445.lst a.ArgTest which is accurate - it is the command line used to launch the program - but I cannot see all of the libs, etc, that went into launching. Simple steps to test with: 1. create a Java Application launch config for any class with a main method 2. add a few eclipse installs worth of jar files to the class path on the classpath tab 3. launch it (In reply to comment #23) > The CLASSPATH environment variable sounds like the best solution. Once bug > 285720 is fixed, this also allows the user to see the classpath even if it's > longer than what the OS can manage. I agree, but the wording in http://support.microsoft.com/kb/830473 indicates that even if the environment variable expands to more that 8191 chars (combined) it will also not work. I'm going to code up an test fix using the CLASSPATH var to see if this is really the case.
Created attachment 218765 [details] updated patch This is an updated version of the patch that contains changes I had to make to get it to apply / test it
> 3. in shortenCommandLine there is a comparison of the command length to 30000, > which seems arbitrary to me, from the MS article the overall length can't > exceed 8191 chars, so shouldn't we compare the complete command to that + if > the OS is Windows? If so then augment the classpath (as needed). I don't know where you got this number: 8191. From MSDN page for CreateProcess(): > The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character.
Comment on attachment 218765 [details] updated patch This hack is unnecessary and should be avoided. What's the argument against comment 23?
Comment on attachment 218765 [details] updated patch (In reply to comment #42) Sorry, I got distracted because the attachment was not marked as patch. If the environment variable is indeed also bounded, then the hack might be the right solution.
(In reply to comment #41) > > 3. in shortenCommandLine there is a comparison of the command length to 30000, > > which seems arbitrary to me, from the MS article the overall length can't > > exceed 8191 chars, so shouldn't we compare the complete command to that + if > > the OS is Windows? If so then augment the classpath (as needed). > > I don't know where you got this number: 8191. > From MSDN page for CreateProcess(): > > The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character. Indeed it does. The relevant MSDN link is: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx I was going by what could be executed via the command prompt as mentioned here: http://support.microsoft.com/kb/830473. The fix works using a classpath that is much greater than 32K chars in size, so we can safely assume the CreateProcess limits should be used.
> What's the argument against comment 23? CLASSPATH works on Windows 7. 1) It should be tested on Windows XP 2) It may have it's own limit: 64k, 128k?
Created attachment 218771 [details] patch using the CLASSPATH var Here is a patch that uses the CLASSPATH variable. I tested it using a class path of 170201 characters, so it does not appear like there is a limit (or if there is one it is very high). The bonuses of this approach is that the fix is simpler logic and you can see all of the libraries involved in the launch in the Environment section on the process properties page. The downside seems to be that the process properties pages seems to open quite a bit slower now.
(In reply to comment #46) > Created attachment 218771 [details] [diff] > patch using the CLASSPATH var This approach looks good. > if(env[i].startsWith("CLASSPATH")) { ... Shouldn't it be: ... ("CLASSPATH=")) { ... ? I'm not sure about the details in checkClasspath: - To calculate the command line length, don't you have to call renderCommandLine(String[]) to make sure you also include the spaces between arguments and the quotes around arguments? - The test should be "if(size > 32767)" (account for terminating null) > The downside seems to be that the process properties > pages seems to open quite a bit slower now. Can you try removing SWT.WRAP and adding SWT.H_SCROLL to the Text widget? Or maybe use a StyledText instead.
(In reply to comment #47) > > This approach looks good. > > > if(env[i].startsWith("CLASSPATH")) { ... > Shouldn't it be: ... ("CLASSPATH=")) { ... ? > Yes, otherwise we could end up appending CLASSPATH_VS or something else not what we want :) > I'm not sure about the details in checkClasspath: > - To calculate the command line length, don't you have to call > renderCommandLine(String[]) to make sure you also include the spaces between > arguments and the quotes around arguments? renderCommandLine is a helper method to 'pretty print' the command line, which is stored in the process attributes. When we actually launch the process we pass in the raw command line, see StandardVMRunner line 324 for an example. > - The test should be "if(size > 32767)" (account for terminating null) Ah! good catch. > Can you try removing SWT.WRAP and adding SWT.H_SCROLL to the Text widget? Or > maybe use a StyledText instead. I'll try both to see which one looks / behaves the niceset
Created attachment 218816 [details] updated CLASSPATH var patch This updated patch has the fixes mentioned in comment #47 The fix to the ProcessPropertyPage has been pushed to: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=efd7c3127870daab51ebfbc3a2e9b5f262651d1b
Curtis, could you please test the fix (you still have access to a Windows XP machine and we need to make sure the long system variables work there as well)? FWIW, I tested the fix on Windows 8 and it works fine.
StandardVMRunner and Standard11xVMRunner are not good. If I choose to inherit environment variables, then envp was null here, but newenvp doesn't contain the other variables: String[] newenvp = checkClasspath(arguments, cp, envp); In the end, exec(..) is called with only the CLASSPATH variable set. In the StandardVMDebugger, the same problem does not occur on my system because prependJREPath(..) explicitly sets the environment. prependJREPath(..) uses equalsIgnoreCase(..) to match variable names. I think StandardVMRunner#getCPIndex(String[]) needs to do the same. The rest looks good, except for formatting (missing spaces in "if(condition)").
+1 The updated classpath var patch allows the long command line to run on Win XP.
How do I add this patch to my version of eclipse?
Pushed patch + suggested fixes from comment #51 to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=a24b7af73c4e08e7b05935d30be10b1afd046dcc (In reply to comment #53) > How do I add this patch to my version of eclipse? You would need the JDT debug source, and then you could export the patched version into Eclipse OR you could wait for an N build from tonight or the I build from next Tuesday
(In reply to comment #54) StandardVMRunner#checkClasspath(List<String>, String[], String[]) line 427 is now: newenvp[idx] = key+'='+value+File.pathSeparatorChar; The "+File.pathSeparatorChar" is wrong and must be removed. When re-reading the "-classpath" section of http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html#standard , I realized that the current behavior is wrong if a CLASSPATH env variable exists. For normal launches, we always add a "-classpath" command line argument, and this overrides any CLASSPATH env var. So, we must not append the classpath to the env var, but override it.
Created attachment 218870 [details] last changes With this patch, all Run and Debug scenarios I could come up with are working fine.
(In reply to comment #56) > Created attachment 218870 [details] > last changes > > With this patch, all Run and Debug scenarios I could come up with are working > fine. Pushed to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=d175f8d9ea16b28a0f2a79d2e972a887ec333db8
Testing on Linux, Curtis and I managed to cause a create process failure. Linux also has an upper limit for the overall command length, so we should apply this fix to all platforms based on their create process limits. Curtis will post a stacktrace from Ubuntu 11.04
eclipse.buildId=I20120710-0800 java.version=1.7.0-ea java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_CA Framework arguments: -product org.eclipse.sdk.ide -showlocation Command-line arguments: -product org.eclipse.sdk.ide -data /home/cwindatt/WS/Workspace Target -dev file:/home/cwindatt/WS/Workspace/.metadata/.plugins/org.eclipse.pde.core/Target/dev.properties -os linux -ws gtk -arch x86 -consoleLog -console -showlocation Error Wed Jul 18 11:16:10 CDT 2012 Exception occurred executing command line. java.io.IOException: Cannot run program "/home/cwindatt/Java/jdk7/jdk1.7.0/bin/java" (in directory "/home/cwindatt/WS/Workspace Target/testJava"): error=7, Argument list too long at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) at java.lang.Runtime.exec(Runtime.java:615) at org.eclipse.debug.core.DebugPlugin.exec(DebugPlugin.java:861) at org.eclipse.jdt.launching.AbstractVMRunner.exec(AbstractVMRunner.java:87) at org.eclipse.jdt.internal.launching.StandardVMRunner.run(StandardVMRunner.java:332) at org.eclipse.jdt.launching.JavaLaunchDelegate.launch(JavaLaunchDelegate.java:101) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:855) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:704) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1018) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1222) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Caused by: java.io.IOException: error=7, Argument list too long at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.<init>(UNIXProcess.java:135) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1021) ... 10 more http://www.in-ulm.de/~mascheck/various/argmax/
1) The fix only runs for Windows 2) There is a bug at the end of the checkClasspath method. If the classpath var doesn't exist a new array newenv is created, but never returned. 3) Even after fixing these issues, it still fails. The limit appears to be the command buffer. cwindatt@CWindatt-LKKPFHC:~$ xargs --show-limits Your environment variables take up 2605 bytes POSIX upper limit on argument length (this system): 2092499 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 2089894 Size of command buffer we are actually using: 131072 Running with just over 131072 characters fails, below that amount works.
(In reply to comment #60) > 1) The fix only runs for Windows > 2) There is a bug at the end of the checkClasspath method. If the classpath > var doesn't exist a new array newenv is created, but never returned. > 3) Even after fixing these issues, it still fails. The limit appears to be the > command buffer. > > cwindatt@CWindatt-LKKPFHC:~$ xargs --show-limits > Your environment variables take up 2605 bytes > POSIX upper limit on argument length (this system): 2092499 > POSIX smallest allowable upper limit on argument length (all systems): 4096 > Maximum length of command we could actually use: 2089894 > Size of command buffer we are actually using: 131072 > > Running with just over 131072 characters fails, below that amount works. With the available space for a command to create a Unix process being a computation of available_stack_space * 1/3 (or so), and that space has to include the command + all args + the combined expanded environment I don't think the CLASSPATH fix is sufficient. We might have to revisit the fix for this bug using the approach from Ilya's patch where we write class path entries to a temp file and read them in via a delegate main class. FWIW the limit on our Mac is a bit higher than Curtis' 'nix box, coming in at 262144
pushed missing return call to: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=a60c443fa6fb3805fb833961f974a7d50d17d200
I would revert this bug to "Platform: Windows" and declare success for now. Or at least use a separate bug for the other platforms and set it to P5 (aka RESOLVED/LATER). The limits on the other platforms are high enough that nobody had an issue so far. And the limits will grow as the platforms evolve, so it will likely also not be a problem in the future.
(In reply to comment #63) > I would revert this bug to "Platform: Windows" and declare success for now. > Or at least use a separate bug for the other platforms and set it to P5 (aka > RESOLVED/LATER). > > The limits on the other platforms are high enough that nobody had an issue so > far. And the limits will grow as the platforms evolve, so it will likely also > not be a problem in the future. Makes sense. I opened bug 385738 for the *nix case. Re-closing as fixed for Windows.
@Ilya Basin I've been trying to track down how to implement this patch, and you've made a few comments on the bug thread. I was hoping you could give me some direction patching the org.eclipse.jdt.launching_3.4.2.v20110411_r342.jar I have Rational Application Developer 7.5.5.4 and I'm trying to figure out the best way to patch this myself for my machine. It's a corporate tool, no way I can upgrade... So I need to patch it. I believe that I'd be patching :Version: 3.4.2.r342_v20081217-7o7tEAoEEDWEm5HTrKn-svO4BbDI when I look @ the eclipse.jdt feature. I saw that you had the patch for 3.5 and 3.6.. is there any chance you have the patch for 3.4.2? Else could you direct me how I'd be able to use your 3.5 patch and retro fit it to the 3.4? -tadudek@gmail.com - thanks
(In reply to comment #65) Hi! First, you need the cvs client, the patch tool and the 2 source files of the corresponding version: StandardVMRunner.java and StandardVMDebugger.java . They can be found in CVS :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse org.eclipse.jdt.launching/launching The tag, I presume, is R3_4_2, so the commands would be: $ cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse co -r R3_4_2 org.eclipse.jdt.launching/launching $ cd org.eclipse.jdt.launching $ patch -N -p1 -i ../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch Now you only need 3 java files: launching/org/eclipse/jdt/internal/launching/LongCommandLineLauncher.java launching/org/eclipse/jdt/internal/launching/StandardVMDebugger.java launching/org/eclipse/jdt/internal/launching/StandardVMRunner.java Delete all other java files. Create an empty java project in Eclipse in the existing folder org.eclipse.jdt.launching. Set java compiler version to 1.4. Add the folder "launching" as source folder. Add all .jar files from your Rational Application Developer plugins/ folder to the build path. If the patch failed, you will need to manually resolve the conflicts. Now the files should compile without error. I had an error in my patch: lclExtractWriter.append . It should be "write", not "append", because the method "append" is since java 1.5. Now you can find the compiled .class files and replace them in the .jar file.
@Ilya Basin So, a few things. I'm on a windows box. I can navigate through the CVS plugin on RAD to org.eclipse.jdt.launching, but the tag I see that I think I'm looking for is v20110411_r342. I'm able to bring that into my workspace as a project. I do not see "../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch" I'm guessing that this is the patch file I'm going to create, but correct me if I'm wrong. I downloaded cygwin to be able to run 'patch', but should be able to create it via the eclipse plugin I think. I do see org.eclipse.jdt.internal.launching.StandardVMRunner.java org.eclipse.jdt.internal.launching.StandardVMDebugger.java From the org.eclipse.jdt.launching project I was able to bring in. I do not see LongCommandLineLauncher I'm not sure where this is supposed to exist. Can you answer my questions about the patch file, and about where the LongCommandLineLauncher is supposed to be? -Tim (In reply to comment #66) > (In reply to comment #65) > Hi! First, you need the cvs client, the patch tool and the 2 source files of > the corresponding version: StandardVMRunner.java and StandardVMDebugger.java > . > > They can be found in CVS > :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse > org.eclipse.jdt.launching/launching > The tag, I presume, is R3_4_2, so the commands would be: > $ cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse co -r R3_4_2 > org.eclipse.jdt.launching/launching > $ cd org.eclipse.jdt.launching > $ patch -N -p1 -i > ../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch > > Now you only need 3 java files: > launching/org/eclipse/jdt/internal/launching/LongCommandLineLauncher.java > launching/org/eclipse/jdt/internal/launching/StandardVMDebugger.java > launching/org/eclipse/jdt/internal/launching/StandardVMRunner.java > Delete all other java files. > Create an empty java project in Eclipse in the existing folder > org.eclipse.jdt.launching. > Set java compiler version to 1.4. > Add the folder "launching" as source folder. > Add all .jar files from your Rational Application Developer plugins/ folder > to the build path. > If the patch failed, you will need to manually resolve the conflicts. > Now the files should compile without error. > I had an error in my patch: lclExtractWriter.append . It should be "write", > not "append", because the method "append" is since java 1.5. > Now you can find the compiled .class files and replace them in the .jar file.
Got cvs to work, but struggling with the patch tool. Where can I find the patch file? dudekta@C001460186 ~ $ patch -N -p1 -i ../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch patch: **** Can't open patch file ../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch : No such file or direc tory -Tim We can take this off the board here @ my email address for my acct that I mailed you from. (In reply to comment #66) > (In reply to comment #65) > Hi! First, you need the cvs client, the patch tool and the 2 source files of > the corresponding version: StandardVMRunner.java and StandardVMDebugger.java > . > > They can be found in CVS > :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse > org.eclipse.jdt.launching/launching > The tag, I presume, is R3_4_2, so the commands would be: > $ cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse co -r R3_4_2 > org.eclipse.jdt.launching/launching > $ cd org.eclipse.jdt.launching > $ patch -N -p1 -i > ../../0001-fix-bug-327193-CreateProcess-error-87-on-windows-whe.patch > > Now you only need 3 java files: > launching/org/eclipse/jdt/internal/launching/LongCommandLineLauncher.java > launching/org/eclipse/jdt/internal/launching/StandardVMDebugger.java > launching/org/eclipse/jdt/internal/launching/StandardVMRunner.java > Delete all other java files. > Create an empty java project in Eclipse in the existing folder > org.eclipse.jdt.launching. > Set java compiler version to 1.4. > Add the folder "launching" as source folder. > Add all .jar files from your Rational Application Developer plugins/ folder > to the build path. > If the patch failed, you will need to manually resolve the conflicts. > Now the files should compile without error. > I had an error in my patch: lclExtractWriter.append . It should be "write", > not "append", because the method "append" is since java 1.5. > Now you can find the compiled .class files and replace them in the .jar file.
Created attachment 219900 [details] bug327193_3.4.2_hack.zip Why don't you go with the fix that was applied to 4.3 and was approved by the Eclipse committers? The fix was in these 3 patches: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/?id=a24b7af73c4e08e7b05935d30be10b1afd046dcc http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/?id=d175f8d9ea16b28a0f2a79d2e972a887ec333db8 http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/?id=a60c443fa6fb3805fb833961f974a7d50d17d200 I've applied them to the R3_4_maintenance branch (needed a few manual tweaks), and created a combined patch. However, since your version of org.eclipse.jdt.launching is not the one from the official 3.4.2 build, the best fix is to just replace the class files (and remove the signing information): - copy your eclipse/plugins/org.eclipse.jdt.launching_3.4.*.jar to a safe place outside of the plugins folder, so that you always have a way to revert - close Eclipse - rename the *.jar to *.zip - open the zip file and copy the 4 class files from the attachment to org\eclipse\jdt\internal\launching (replace existing files) - go to META-INF in the zip file and delete all files except MANIFEST.MF - extract MANIFEST.MF to your disk and edit it with a text editor - remove everything starting from the first "NAME:" entry - make sure you leave *two* (2) line break characters at the end of the file! - save the MANIFEST.MF and copy it back into the zip file - rename the *.zip back to *.jar - enjoy
Sent you a mail. I was able to follow your steps no problem, but that approach didn't work Markus. I gave that a shot, but it seems that I get a slew of problems associated to project facets. 'Target runtime was.base.v7 is not defined' Warnings in project facets: Implementation of project facet web.siteedit could not be found Functionality will be limited. Implementation of project facet web.template could not be found Functionality will be limited. Implementation of project facet com.ibm.websphere.coexistence.web could not be found Functionality will be limited. Implementation of project facet com.ibm.websphere.extended.web could not be found Functionality will be limited. Implementation of project facet jst.java could not be found Functionality will be limited. Implementation of project facet jst.web could not be found Functionality will be limited. Not totally sure how to approach this. I replaced my old jar, and rebuilt -clean, then had to revert. (In reply to comment #69) > Created attachment 219900 [details] > bug327193_3.4.2_hack.zip > > Why don't you go with the fix that was applied to 4.3 and was approved by > the Eclipse committers? > > The fix was in these 3 patches: > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/ > ?id=a24b7af73c4e08e7b05935d30be10b1afd046dcc > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/ > ?id=d175f8d9ea16b28a0f2a79d2e972a887ec333db8 > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/patch/ > ?id=a60c443fa6fb3805fb833961f974a7d50d17d200 > > I've applied them to the R3_4_maintenance branch (needed a few manual > tweaks), and created a combined patch. > > However, since your version of org.eclipse.jdt.launching is not the one from > the official 3.4.2 build, the best fix is to just replace the class files > (and remove the signing information): > - copy your eclipse/plugins/org.eclipse.jdt.launching_3.4.*.jar to a safe > place outside of the plugins folder, so that you always have a way to revert > - close Eclipse > - rename the *.jar to *.zip > - open the zip file and copy the 4 class files from the attachment to > org\eclipse\jdt\internal\launching (replace existing files) > - go to META-INF in the zip file and delete all files except MANIFEST.MF > - extract MANIFEST.MF to your disk and edit it with a text editor > - remove everything starting from the first "NAME:" entry > - make sure you leave *two* (2) line break characters at the end of the file! > - save the MANIFEST.MF and copy it back into the zip file > - rename the *.zip back to *.jar > - enjoy
(In reply to comment #70) > Sent you a mail. I was able to follow your steps no problem, but that > approach didn't work Markus. For the records: The problem was that Tim had an intermediate folder in the resulting Zip/Jar file. It works fine when META-INF etc. are at the top level inside the Zip.
Forgive the stupid question, but was this also backported to Juno 4.2.x stream for release in Juno SR1 this month, or just in the Kepler 4.3 trunk stream? Seems a pretty important thing to fix as it affects all Windows users.
(In reply to comment #72) > Forgive the stupid question, but was this also backported to Juno 4.2.x > stream for release in Juno SR1 this month, or just in the Kepler 4.3 trunk > stream? Its only fixed in 4.3, we did not put it in SR1 (or further back) because it is not a major problem for most users.
Markus Keller: Thanks for the long explanation how to build the JAR. Can you please *build* such a JAR for everyone and attach it to this big with instructions how to install it manually in Eclipse?
(In reply to comment #74) I'm sorry to disappoint you, but no. It could be backported to 3.8.2/4.2.2 (Mike?), but that's all I can do. I didn't attach a ready-made JAR, because there is none that works in every install. I don't have time to do this for every past release.
Could you please fix this bug also in 4.2? We are now gradually moving to e4 in our organization and develop projects with very long class paths (JBoss, EMF etc.). This problem significantly constrains our productivity. Our more than 1000 developers need the quick feedback of running the JUnit tests inside Eclipse.
(In reply to comment #76) > Could you please fix this bug also in 4.2? We are now gradually moving to e4 > in our organization and develop projects with very long class paths (JBoss, > EMF etc.). This problem significantly constrains our productivity. Our more > than 1000 developers need the quick feedback of running the JUnit tests > inside Eclipse. It's already backported, see bug 393675.
Hi all, I found a convenient workaround on Windows 7 : you can create a symbolic link since Windows Vista. I created it to reference my Eclipse workspace with a shorter path and switched to my workspace with the newly created path and everything worked. Here is the command I used : in E:\Projects mklink /D newWorkspace E:\Projects\myProject\Dev\workspaces\muleWorkspace Hope this helps. Regards, Christophe
I'm personally experiencing this issue with Kepler [Version: Kepler Service Release 1, Build id: 20130919-0819]. I thought it had been fixed. Has is not? Is there patch or work-around?
(In reply to Jimisola Laursen from comment #79) > I'm personally experiencing this issue with Kepler [Version: Kepler Service > Release 1, Build id: 20130919-0819]. > > I thought it had been fixed. Has is not? Is there patch or work-around? It is considered fixed. If you still see this, please file a new bug report with exact steps to reproduce.
@Dani Megert So far, I've been able to reproduce when trying to unit test an Android Project (problem occurs with both JUnit and TestNG). I've just posted in the testng-users since this issue was mentioned there two years ago. Could be that I'm doing something wrong, but the problem does not exist if I move the .java file containing the test to a normal Java Project and run it there. I've created a new bug #422181
Created attachment 249143 [details] Patched org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar This is the org.eclipse.jdt.launching_3.6.1.v20111006_r372.jar file with the .class files patched in to address the bug. Can be used as is (with the -clean option on first startup), as described in the discussion thread for this bug.
I am facing the same error while running the unit test in the latest Eclipse for Enterprise Java Developers. Do we have fix for it?
