1. EuCOM and Interpreter Bugginess

There's something very strange going on here. If I run EuCOM.ew (in a 
program or by itself to test), there are some weird results when there are 
missing include files. If unicode.ew is missing, it works correctly. Namely, 
it prints out that it can't find unicode.ew and waits. If, however, 
unicode.ew exists and variant.ew or comerr.ew do not, the interpreter does 
not error out properly. Initially, it prints out the name and EUINC path, 
but before it can print out what the error really is, another machine error 
occurs. This prints out its own message, which would be alright, but then it 
procedes to crash entirely, without writing an ex.err.
The strange thing is: a) there is no code between the include statements for 
unicode.ew, variant.ew, and comerr.ew, b) there is no code executed in 
unicode.ew that could cause this sort of problem (there are only function 
links), and c) of course the fact that the interpreter decides to royally 
crash too.

PS. Matt, you really should add "without warning" when you release EuCOM.

PPS. Matt, I didn't know you were an actor in disguise: 
http://www.imdb.com/name/nm0507535/

new topic     » topic index » view message » categorize

2. Re: EuCOM and Interpreter Bugginess

Elliott S. de Andrade wrote:
> There's something very strange going on here. If I run EuCOM.ew (in a 
> program or by itself to test), there are some weird results when there are 
> missing include files. If unicode.ew is missing, it works correctly. Namely, 
> it prints out that it can't find unicode.ew and waits. If, however, 
> unicode.ew exists and variant.ew or comerr.ew do not, the interpreter does 
> not error out properly. Initially, it prints out the name and EUINC path, 
> but before it can print out what the error really is, another machine error 
> occurs. This prints out its own message, which would be alright, but then it 
> procedes to crash entirely, without writing an ex.err.

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.

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: EuCOM and Interpreter Bugginess

>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

new topic     » goto parent     » topic index » view message » categorize

4. Re: EuCOM and Interpreter Bugginess

Elliott S. de Andrade wrote:
> 
> There's something very strange going on here. If I run EuCOM.ew (in a 
> program or by itself to test), there are some weird results when there are 
> missing include files. If unicode.ew is missing, it works correctly. Namely, 
> it prints out that it can't find unicode.ew and waits. If, however, 
> unicode.ew exists and variant.ew or comerr.ew do not, the interpreter does 
> not error out properly. Initially, it prints out the name and EUINC path, 
> but before it can print out what the error really is, another machine error 
> occurs. This prints out its own message, which would be alright, but then it 
> procedes to crash entirely, without writing an ex.err.
> The strange thing is: a) there is no code between the include statements for 
> unicode.ew, variant.ew, and comerr.ew, b) there is no code executed in 
> unicode.ew that could cause this sort of problem (there are only function 
> links), and c) of course the fact that the interpreter decides to royally 
> crash too.

That's really odd.  I've never had a problem like this...What are you 
running (machine/OS)?

> PS. Matt, you really should add "without warning" when you release EuCOM.

Yes, I usually put that into things, so this was likely a little 
oversight.

> PPS. Matt, I didn't know you were an actor in disguise: 
> <a
> href="http://www.imdb.com/name/nm0507535/">http://www.imdb.com/name/nm0507535/</a>

Oh, well, you found me. :P

Matt Lewis

new topic     » goto parent     » topic index » view message » categorize

5. Re: EuCOM and Interpreter Bugginess

>From: Matt Lewis <guest at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: EuCOM and Interpreter Bugginess
>Date: Fri, 04 Jun 2004 03:52:45 -0700
>
>posted by: Matt Lewis <matthewwalkerlewis at yahoo.com>
>
>Elliott S. de Andrade wrote:
> >
[some stuff I had said. go look on the forum to see what it was....;)]
>
>That's really odd.  I've never had a problem like this...What are you
>running (machine/OS)?
>

  I'm running Windows XP Pro. Also, as I mentioned in the other e-mail, this 
error doesn't happen when file.e is missing. Well, I was wrong about that, 
the error occurs there as well. So, it seems, nothing wrong with namespacing 
(darn, Eu still doesn't have a bug ;), just some sort of bug in EuCOM.

~[ WingZone ]~
http://wingzone.tripod.com/

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu