1. Bug or Expected Behavior with Compiled Code
- Posted by euphoric (admin) Jun 28, 2011
- 1456 views
I have a program that crashes with an unhelpful message when the code is compiled. This might be the way it has to be, but I thought I'd ask...
When I run the program interpreted, I get a normal error message:
C:\Users\Owner\My Programs\add_inventory\add_inventory.exw:111 in procedure main() slice starts past end of sequence (1 > 0) ... called from C:\Users\Owner\My Programs\add_inventory\add_inventory.exw:248
When I run it compiled, I get a dialog box whose title is "Assertion Failed." The body of the dialog box has one line that reads, "size >= 0, function NewS1, file be_alloc.c, line 818."
Line 111 of the source is:
vTime = vTime[1..6]
and vTime = {} at the time of the error.
Is this expected crash behavior for the compiled code? Does the error message of the compiled program have to be this useless (to me), or could it specify the actual error (trying to access non-existent sequence element[s])?
2. Re: Bug or Expected Behavior with Compiled Code
- Posted by DerekParnell (admin) Jun 28, 2011
- 1440 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.
3. Re: Bug or Expected Behavior with Compiled Code
- Posted by euphoric (admin) Jun 28, 2011
- 1446 views
Thanks, Derek! Clear and reasonable rationale.
