OpenEuphoria

Re: EuCOM and Interpreter Bugginess

• Posted by "Elliott S. de Andrade" <quantum_analyst at hotmail.com> Jun 04, 2004
• 797 views

>From: Robert Craig <guest at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: EuCOM and Interpreter Bugginess
>Date: Thu, 03 Jun 2004 17:37:27 -0700
>
>posted by: Robert Craig <rds at RapidEuphoria.com>
>
>Elliott S. de Andrade wrote:
[ There was stuff from me written here before. ]
>
>When a machine-level exception occurs, there is no guarantee that
>the interpreter will be able to complete the process of writing
>ex.err, without itself crashing. Things may be too corrupted in memory.
>Just by trying to unwind the call stack or print a variable,
>the interpreter might use a pointer that the application
>corrupted.
>
>Actually, there is always a remote chance that an application
>that uses pokes etc, will corrupt things badly enough that
>the interpreter will not be able to terminate properly with an ex.err.
>But it's especially likely when a machine-level exception is reported.
>

Yes, I realize that may happen. The strange thing of course is when it 
happens. Why would it print out two error messages? Eucom.ew is laid out 
like this:

include get.e
include dll.e
include machine.e
include tk_mem.e as mem
include fptr.e as fptr
include unicode.ew as u
include variant.ew as v
include file.e
include comerr.ew as err

Now, if anything above variant.ew is missing, the error message is printed 
out correctly. For missing variant.ew or comerr.ew, both could cause a 
machine exception to occur. However, if file.e is missing, the error message 
is printed correctly, without a crash. This appears to be some sort of 
namespacing parsing error.
There is almost no code in Eucom to poke anything in memory at the time. 
None of the functions have been called, I'm just running "exw eucom.ew". The 
only thing that happens is the allocating space for the assembler code, 
which should be well tested and not cause errors. I looked over it myself, 
too; seems fine. The only other place with poking (an init section) does not 
change the double-error problem if commented out. I know for certain these 
are the only places accessing memory because I've profiled the code to see.

>Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com