1. Run-time error with rev 1285
- Posted by RStowasser Dec 29, 2008
- 1009 views
Hello Matt,
among other applications I always run IDE104 (with some minor modifications) and standalone Editor with a new svn version of exw as I think if they work ok then 99.9% of older programs will work too. With rev 1280 there is no problem.
This time (rev 1285) I have a problem with running exw.exe / exwc.exe and IDE.exw.
IDE translated / compiled runs ok.
Running exw.exe and IDE.exw there is an error message:
Fatal run-time error:
slice upper index is less than 0 (-1)
Running exwc.exe and IDE.exw shows this message:
Fatal run-time error:
slice upper index is less than 0 (-1)
The instruction at 0x0049c3c3 referenced memory at 0x00000004.
The memory could not be written.
Exception fielded by 0x004a97e0
etc...
Running eu.ex and IDE shows this result:
C:\EUPHORIA\SOURCE40>exwc eu.ex d:\euphoria\ide104\ide.exw
.\emit.e:142 in function Pop()
subscript value 0 is out of bounds, reading from a sequence of length 0
... called from .\parser.e:1658 in procedure Return_statement()
... called from .\parser.e:3096 in procedure Statement_list()
... called from .\parser.e:1970 in procedure If_statement()
... called from .\parser.e:3088 in procedure Statement_list()
... called from .\parser.e:1970 in procedure If_statement()
... called from .\parser.e:3088 in procedure Statement_list()
... called from .\parser.e:1970 in procedure If_statement()
... called from .\parser.e:3088 in procedure Statement_list()
... called from .\parser.e:1970 in procedure If_statement()
... called from .\parser.e:3088 in procedure Statement_list()
... called from .\parser.e:3361 in procedure SubProg()
... called from .\parser.e:3644 in procedure real_parser()
... called from .\parser.e:3819 in procedure parser()
... called from .\main.e:256 in procedure main()
... called from .\main.e:276
> See ex.err
Press Enter...
Unfortunately there is no hint in ex.err when this situation happens in IDE.exw. Maybe some nested if statements in a procedure?
Roland
2. Re: Run-time error with rev 1285
- Posted by mattlewis (admin) Dec 29, 2008
- 1026 views
This time (rev 1285) I have a problem with running exw.exe / exwc.exe and IDE.exw.
IDE translated / compiled runs ok.
Running exw.exe and IDE.exw there is an error message:
Fatal run-time error:
slice upper index is less than 0 (-1)
Yes, I discovered this issue this morning, and thought I might hear from you. :)
This bug is an easy fix (and just committed as r1287, BTW), however, there is something else going on once that issue is dealt with. There were some fairly significant changes made to the way forward references are handled, and that is where the new bug is. The bug you found here was again with tail recursion, and trying to pop a value off of the code gen stack when I shouldn't have.
Matt
3. Re: Run-time error with rev 1285
- Posted by RStowasser Dec 29, 2008
- 1013 views
- Last edited Dec 30, 2008
This bug is an easy fix (and just committed as r1287, BTW), however, there is something else going on once that issue is dealt with. There were some fairly significant changes made to the way forward references are handled, and that is where the new bug is. The bug you found here was again with tail recursion, and trying to pop a value off of the code gen stack when I shouldn't have.
Matt
When using rev 1287 IDE again runs fine when translated / compiled and fails if running with exw.exw or exwc.exe. Running IDE with Eu.exw shows a different error message now:
C:\EUPHORIA\SOURCE40>exwc eu.ex
Euphoria Interpreter 4.0 (development) for 32-bit Windows.
SVN Revision 1287
Using System Memory
Copyright (c) Rapid Deployment Software 2008
See http://www.RapidEuphoria.com/License.txt
file name to execute? d:\euphoria\ide104\ide.exw
.\shift.e:300 in procedure shift()
attempt to subscript an atom
(reading from it)
... called from .\shift.e:334 in procedure replace_code()
... called from .\fwdref.e:346 in procedure patch_forward_type_check()
... called from .\fwdref.e:556 in procedure Resolve_forward_references()
... called from .\parser.e:3818 in procedure parser()
... called from .\main.e:256 in procedure main()
... called from .\main.e:276
> See ex.err
Press Enter...
I tried to add the statements: with trace and trace(3) at the beginning of IDE.exw to see if I can find something in ctrace.out, but most surprisingly IDE now runs with exw.exe as well as with eu.exw. This was not expected.
Roland
4. Re: Run-time error with rev 1285
- Posted by mattlewis (admin) Dec 29, 2008
- 966 views
- Last edited Dec 30, 2008
When using rev 1287 IDE again runs fine when translated / compiled and fails if running with exw.exw or exwc.exe. Running IDE with Eu.exw shows a different error message now:
[snip]
I tried to add the statements: with trace and trace(3) at the beginning of IDE.exw to see if I can find something in ctrace.out, but most surprisingly IDE now runs with exw.exe as well as with eu.exw. This was not expected.
This doesn't surprise me too much. The problem is in the way that forward references are handled. Before r1285, we padded code to make sure we always had enough room to do whatever we needed. And if we needed more, we emitted some spaghetti code that jumped around, doing whatever it needed. This worked, but was less than optimal.
The parser now is able (well, mostly, as you've noticed) to remove or replace code so that we can be more flexible in the way we emit code. I think this will also enable us to possibly do some other optimizations in the future. But the size of the emitted operations change based on things like the translator, trace mode, etc, and the IDE is obviously exposing a case that hasn't been accounted for yet.
Matt
5. Re: Run-time error with rev 1285
- Posted by mattlewis (admin) Dec 30, 2008
- 966 views
I tried to add the statements: with trace and trace(3) at the beginning of IDE.exw to see if I can find something in ctrace.out, but most surprisingly IDE now runs with exw.exe as well as with eu.exw. This was not expected.
It was an issue with shifting a tail call. With trace, it wasn't resolving to a tail call due to the way they are detected. There are extra ops emitted when trace is on, causing the tail call detection to fail (which should probably be fixed).
The error itself was a simple fix. Please try r1288.
Matt
