Hi,
Our latest build result reported that it had succeeded, yet the build log shows a number of failures with the execute program action. Each of the actions are executing a different program, so it seems to be an error with the actual action itself.
Whats more annoying is that it will terminate execution of the called action list (and is not handled by the try/catch action blocks that is parented to the action), and will continue on as normal in the main action list.
A second run of the project seems to run fine, so its not something I can reproduce. This is a big concern for us. This is the only “known” case that we have seen, but we now have no idea on the quality of our code and requires us to look at every build log to validate its success.
example output from the static log:
Error Execute Program project 05:42:08 05:42:08 00:00:00 View
Executing external process: make.exe
Starting Directory: C:\project
Parameters: clean all
Output from make.exe
Program returned code : 1001
-Dave
Some more information,
currently using the latest 6.3 release of FB, and the project is being run using FB Server. Server host is 64bit vista machine.
-Dave.
Hi Dave
Do you specify the full path to the executable in the action? What settings do you have on the action? I suspect this may be a side effect to a change we made to deal with WoW64 file system redirection on 64bit windows. If no path is specified to the exe it’s possible it may find the wrong exe or not find it at all. I wasn’t able to reproduce what you are seeing.
I will post a link to a new build here shortly (it’s building right now).
Hi Dave
Please try this build.
https://www.finalbuilder.com/downloads/finalbuilder/630/FB630_1477.exe
If that doesn’t work then please send your project to support so we can try to reproduce the problem here with the same settings.
I pretty much have all the actions to their default settings. The path of the executable is not specified within the action, it is specified on the PATH, which seems to be correct accordng to the log. There shouldn’t be any conflicts with the executable, but even if thats the case, I wouldn’t expect this output. It would be good if the action could print the path as well as the executable if it is not given inside the action.
Assuming this is some sort of internal issue with the action, is there no way that the build can resume in a more expected behaviour ? either being handled correctly by the try catch block, or raising an exception that cannot be caught and terminating the build early? I’m unable to reproduce the issue here again which is very unfortunatly… it seems to be one of those freaky occassions.