Re: Bug or Expected Behavior with Compiled Code
- Posted by DerekParnell (admin) Jun 28, 2011
- 1441 views
Is this expected crash behavior for the compiled code?
Yes it is.
The reason is because we have taken the approach that an application will be tested using the interpreter and only compiled when it is about to be released for distribution. We do this so as to reduce the code size and increase the performance of the compiled program; we omit a lot of internal checks in the translated code, such as index boundary tests, type tests, divide-by-zero tests, etc ...
Thus it is probable that a program which gives a sensible error message when interpreted, to give a weird message when compiled.
The upshot is that you need to use the interpreter to develop your application and after you have finished testing the app, run it through the translator. You will, of course, need to test the translated code for functionality as well but by then most bugs in your application should have been detected and fixed.
Here is a quote from the documentation...
6.4.8.1 Note:
The Translator assumes that your program has no run-time errors in it that would be caught by the Interpreter. The Translator does not check for: subscript out of bounds, variable not initialized, assigning the wrong type of data to a variable, etc.
You should debug your program with the Interpreter. The Translator checks for certain run-time errors, but in the interest of speed, most are not checked. When translated C code crashes you'll typically get a very cryptic machine exception. In most cases, the first thing you should do is run your program with the Interpreter, using the same inputs, and preferably with type_check turned on. If the error only shows up in translated code, you can use with trace and trace(3) to get a ctrace.out file showing a circular buffer of the last 500 Euphoria statements executed. If a translator-detected error message is displayed (and stored in ex.err), you will also see the offending line of Euphoria source whenever with trace is in effect. with trace will slow your program down, and the slowdown can be extreme when trace(3) is also in effect.
