Community
Participate
Working Groups
Build Identifier: 20100617-1415 I am seeing an unfortunate change in behavior of eclipsec.exe exit codes, I think I tracked it down to the fix of bug 304361 (https://bugs.eclipse.org/304361) Prior to the fix (specifically with org.eclipse.equinox.app_1.3.0.v20100108) an application throwing an exception resulted with e.g. eclipsec.exe exiting with exit code 13. (Looks like this is a standard behavior of EclipseStarter#run, in case 'eclipse.exitcode' is left null.) Now the exit code is 0. Specific use case is running of an org.eclipse.ant.core.antRunner with ant script that fails (exception thrown by one of the tasks) - it used to be possible to detect the failure based on the non-zero exit code. An even easier way to reproduce this is to run antRunner on a non-existing file. It seems to be related to that prior to this fix EclipseAppHandle#run was not setting the eclipse.exitcode in case of exception - Activator#setProperty was after the 'finally' block. Now it is in the 'finally' block, via setInternalResult. And the logic there appears to translate null into 0, vs EclipseStarter#run null -> 13. Observed on Windows 7 64 bit, Eclipse 3.6. Reproducible: Always Steps to Reproduce: 1. Run eclipsec --launcher.suppressErrors -application org.eclipse.ant.core.antRunner -f nosuchfile 2. Examine the error code (e.g. echo %ERRORLEVEL%) Expected (used to be): 13 Produced: 0
Verified same issue exists when staring via launcher: java -jar plugins\org.eclipse.equinox.launcher_1.1.0.v20100507.jar -consolelog -application org.eclipse.ant.core.antRunner -f nosuchfile Besides the exit code = 0, the following message (that used to be produced in these cases) is no longer present: "An error has occurred. See the log file <worspace path>\.metadata\.log." Trying to judge the potential impact, while this apparently affects any application throwing an exception, in case of antRunner it makes me wonder if e.g. failed headless PDE builds may start appearing successful ...
This is a regression that we should fix in 3.6.1.
Created attachment 175782 [details] patch This patch fixes the issue by making sure we do not set the exit code property when the result == null for the call to setInternalResult. In that case we assume it is an exception case. The value of NULL_RESULT is used if the application exits without exception with a null result.
Patch released to HEAD and 3.6.x stream.
