Crashproofing - test cases 
Author Message
 Crashproofing - test cases

Here are some test cases which I've tried out on the 3 ANS Forths I have
loaded.  

: BadExecute ( -- ) 4 EXECUTE ;


: BadReturn ( -- ) -1 >R ;
: BadCode ( -- ) 0 ['] DROP !  0 DROP ;

giving the results:

      BadExecute   BadAddress   BadAlign     BadReturn    BadCode
      ==========   ==========   ========     =========    =======
F-PC for DOS v3.5
      Hangs :(     Legal        Legal        Hangs :(     Legal
GForth for DOS v0.1beta
      Exits Forth  Exits Forth  Exits Forth  Exits Forth  Exits Forth
Win32Forth v3.4
      Trapped      Trapped      Legal        Trapped      Trapped then
                                                          exits Forth

In my book, "hangs" and "exits Forth" are both bad news.  Win32Forth
wins applause as it not only traps all the errors, but in the first 4
cases it reports the offending word being executed.

Anyone know how the other Forths behave? or suggest better test cases?

Bye for now                                                      
                                           ____/  /  __  /   /   /   /   /
Chris Jakeman                             /      /  /  _/   /   /   /  /
                                         __/    /  / __    /   /   /_/
at Peterborough, a cathedral            /      /  /   /   /   /   /  \
city 80 miles north of London.       __/    __/  ____/    ___/ __/   _\  
Where do you come from?          
                              Forth Interest Group United Kingdom Chapter
Voice +44 (0)1733 753489      at http://www.*-*-*.com/



Tue, 25 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases


Quote:
> Here are some test cases which I've tried out on the 3 ANS Forths I have
> loaded.

> : BadExecute ( -- ) 4 EXECUTE ;


> : BadReturn ( -- ) -1 >R ;
> : BadCode ( -- ) 0 ['] DROP !  0 DROP ;
> giving the results:

>      BadExecute   BadAddress   BadAlign     BadReturn    BadCode
>      ==========   ==========   ========     =========    =======
> F-PC for DOS v3.5
>      Hangs :(     Legal        Legal        Hangs :(     Legal
> GForth for DOS v0.1beta
>      Exits Forth  Exits Forth  Exits Forth  Exits Forth  Exits Forth
> Win32Forth v3.4
>      Trapped      Trapped      Legal        Trapped      Trapped then
>                                                          exits Forth

iForth 1.07 WinNT
        Trapped     Trapped      Trapped(*)   Trapped      Legal (**)
mxForth 2.4 WinNT
        Trapped     Trapped      Trapped(*)   Trapped      Legal (**)



(**) It is not trapped, and it's not legal. I can continue as long as I
     don't use DROP in interpretive state and depend on the result. That
     could be quite a long time :-)

I didn't know F-PC was an ANS Forth. Why is overwriting DROP legal?
(it doesn't hang and it doesn't exit, so it must be OK?)

Quote:
> In my book, "hangs" and "exits Forth" are both bad news.  Win32Forth
> wins applause as it not only traps all the errors, but in the first 4
> cases it reports the offending word being executed.

iForth does not report the address. It shows a modal alert box, then
performs ABORT. mxForth does COLD (which unfortunately resets the
dictionary pointer so you have to paste the code in again :).

Quote:
> Anyone know how the other Forths behave? or suggest better test cases?

: BadRes1  9 0 /MOD ;
: BadRes2  0 1 1 UM/MOD ;
: BadBreak BEGIN  AGAIN ;
: BadNumb  1 1 BASE ! . ;

-marcel



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases


Quote:
> I am a bit puzzled by your ** response to this test.
> If ' DROP returns an xt which is the address of the DROP code, then
> 0 ' DROP ! will overwrite the code and 0 DROP will crash the Forth.  Are
> iForth and mxForth unusual in this respect?

: BadCode 0 ['] DROP !   0 DROP ;

In iForth and mxForth "DROP" is a macro that generates inline code. BadCode
affects the DROP colon definition that is in i/mxForth for use outside
of definitions. In iForth macro's are also used by the metacompiler that
generates iForth, so there is no reference to a DROP colon definition in
any system word (I could do BadCode : DROP DROP ; and happily continue).

For mxForth it is a little bit different. mxForth's kernel words start off
with a jump a few cells ahead. The metacompiler has eliminated this extra
jump by adding a few cells to the xt's before calling COMPILE, . To crash
mxForth do : BadCode ['] DROP 20 ERASE  0 DROP ;

Quote:
> I've appended these extra test cases.  Can you return them with results
> for iForth and mxForth, please?

iForth and mxForth do not trap BadAlign, non-alignment is legal (natural).
(I've put you on the wrong track with ALIGN , that should be
ALIGNED ( a -- a') a few of your words were changed as you intended).

\ Test       F-PC for  GForth for    Win32Forth       iForth   mxForth
\            DOS v3.5  DOS v0.1beta  v3.4            v1.07 NT  v2.4 NT
\ ========== ========  ============  ==========      ========  =======
\ BadRes1    Trapped   Exits Forth   Trapped         Trapped   Trapped
\
\ BadRes2    -1 -1     0 0           Trapped         Trapped   Trapped
\
\ BadBreak   Hangs     Hangs         Hangs            ^Break   ^Break
\                                   (Interrupt option fails)
\ BadNumb    Hangs     "1"           Prints a line   Trapped/2  Trapped/2
\                                    of rubbish

^Break    : exits Forth, because NT/Borland C can't do better
            (Linux is much better/easier here).
Trapped/2 : the exception is caught, but Forth can't continue. The problem
            is not the endless loop, but a buffer overrun.
            I intend to fix this.

-marcel



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Hi Marcel,

Many thanks for posting the notes below - just the input I was hoping
for.  I've amended the test cases as you suggest.



Quote:
>(**) It is not trapped, and it's not legal. I can continue as long as I
>     don't use DROP in interpretive state and depend on the result. That
>     could be quite a long time :-)

>I didn't know F-PC was an ANS Forth.

Sorry, a slip-up there.
I'm planning an optional safety-net layer which is ANS compatible.  Of
course, if all the popular ANS Forths are already crash-proof, then I'll
drop the idea.

Quote:
> Why is overwriting DROP legal?
>(it doesn't hang and it doesn't exit, so it must be OK?)

I think it's legal for F-PC in the sense that code and data addresses
are in different address spaces.  0 ' DROP !  just writes 0 in the data
space and doesn't overwrite any code, which is what that test is about.
It's not exactly OK, but writing to the wrong data address is a
different problem from overwriting code.

I am a bit puzzled by your ** response to this test.  
If ' DROP returns an xt which is the address of the DROP code, then
0 ' DROP ! will overwrite the code and 0 DROP will crash the Forth.  Are
iForth and mxForth unusual in this respect?

Quote:
>> Anyone know how the other Forths behave? or suggest better test cases?

I've appended these extra test cases.  Can you return them with results
for iForth and mxForth, please?
Bye for now                                                      
                                           ____/  /  __  /   /   /   /   /
Chris Jakeman                             /      /  /  _/   /   /   /  /
                                         __/    /  / __    /   /   /_/
at Peterborough, a cathedral            /      /  /   /   /   /   /  \
city 80 miles north of London.       __/    __/  ____/    ___/ __/   _\  
Where do you come from?          
                              Forth Interest Group United Kingdom Chapter
Voice +44 (0)1733 753489      at http://www.forth.org/fig/uk/homepage.htm

        \ Find a value not likely to be an execution token.
' DUP CELL+ CONSTANT NotAnXT        
        \ Find an address outside the data space.
-4 ALIGN CONSTANT NotADataAddress  
        \ Find an address which is not aligned.
HERE ALIGN 1+ CONSTANT NotAligned
: BadExecute ( -- ) NotAnXT EXECUTE ;


: BadReturn  ( -- ) NotAnXT >R ;
: BadCode    ( -- ) ['] DROP >R    \ Find an XT

                    0 R> EXECUTE ; \ Try executing it
: BadRes1    ( -- ) 9 0 /MOD ;     \ Divide by zero
: BadRes2    ( -- ) 0 1 1 UM/MOD ; \
: BadBreak   ( -- ) BEGIN AGAIN ;  \ Try interrupt loop
: BadNumb    ( -- ) 1 1 BASE ! . ; \ Loops forever?

\ Test       F-PC for  GForth for    Win32Forth  iForth    mxForth
\            DOS v3.5  DOS v0.1beta  v3.4        v1.07 NT  v2.4 NT
\ ========== ========  ============  ==========  ========  =======
\ BadExecute Hangs     Exits Forth   Trapped     Trapped   Trapped
\                                    "BadExecute"
\ BadAddress Legal     Exits Forth  Trapped TOS &  Trapped Trapped

\ BadAlign   Legal     Exits Forth   Legal       Trapped   Trapped
\ BadReturn  Hangs     Exits Forth   Trapped     Trapped   Trapped
\                                    "UnNest"
\ BadCode    Legal     Exits Forth   Exits Forth **        **
\
\ BadRes1    Trapped   Exits Forth   Trapped     ?         ?
\
\ BadRes2    -1 -1     0 0           Trapped     ?         ?
\
\ BadBreak   Hangs     Hangs         Hangs       ?         ?
\                                   (Interrupt option fails)
\ BadNumb    Hangs     "1"           Prints a line ?       ?
\                                    of rubbish
\
\ ** Fails when DROP is then used interactively.



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

>Here are some test cases which I've tried out on the 3 ANS Forths I have
>loaded.  

>: BadExecute ( -- ) 4 EXECUTE ;


>: BadReturn ( -- ) -1 >R ;
>: BadCode ( -- ) 0 ['] DROP !  0 DROP ;

>giving the results:

>      BadExecute   BadAddress   BadAlign     BadReturn    BadCode
>      ==========   ==========   ========     =========    =======
>F-PC for DOS v3.5
>      Hangs :(     Legal        Legal        Hangs :(     Legal
>GForth for DOS v0.1beta
>      Exits Forth  Exits Forth  Exits Forth  Exits Forth  Exits Forth
>Win32Forth v3.4
>      Trapped      Trapped      Legal        Trapped      Trapped then
>                                                          exits Forth

  4tH V3.1d

Quote:

>In my book, "hangs" and "exits Forth" are both bad news.  Win32Forth
>wins applause as it not only traps all the errors, but in the first 4
>cases it reports the offending word being executed.

>Anyone know how the other Forths behave? or suggest better test cases?

Since 4tH does not have a "classic" interpreter, it always exits exec_4th(),
but always in a controlled manner.

Hans



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

>> Anyone know how the other Forths behave? or suggest better test cases?

>: BadRes1  9 0 /MOD ;
>: BadRes2  0 1 1 UM/MOD ;
>: BadBreak BEGIN  AGAIN ;
>: BadNumb  1 1 BASE ! . ;

4tH V3.1d
    BadRes1: Divide by zero
    BadRes2: (4tH has no UM/MOD)
    BadBreak: Legal
    BadNumb: Bad radix

Hans



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

> : BadRes1  9 0 /MOD ;
> : BadRes2  0 1 1 UM/MOD ;
> : BadBreak BEGIN  AGAIN ;
> : BadNumb  1 1 BASE ! . ;

No problem for Gforth:

badres1  
:5
badres1
^^^^^^^
Error: Floating-point unidentified fault
badres2   ok
.s <2> 0 0  ok
. . 0 0  ok
.s <0>  ok
badbreak  
:10
badbreak
^^^^^^^^
Error: User interrupt
badnumb  1  ok

The "User interrupt" comes from typing ^C. Gforth doesn't take BadRes2
(should it? It's an overflow, other Forth operations don't trap on
overflows, too), bigFORTH does (rest identically).

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

> Here are some test cases which I've tried out on the 3 ANS Forths I have
> loaded.

> : BadExecute ( -- ) 4 EXECUTE ;


> : BadReturn ( -- ) -1 >R ;
> : BadCode ( -- ) 0 ['] DROP !  0 DROP ;

> giving the results:

>       BadExecute   BadAddress   BadAlign     BadReturn    BadCode
>       ==========   ==========   ========     =========    =======
> F-PC for DOS v3.5
>       Hangs :(     Legal        Legal        Hangs :(     Legal
> GForth for DOS v0.1beta
>       Exits Forth  Exits Forth  Exits Forth  Exits Forth  Exits Forth
> Win32Forth v3.4
>       Trapped      Trapped      Legal        Trapped      Trapped then
>                                                           exits Forth

> In my book, "hangs" and "exits Forth" are both bad news.  Win32Forth
> wins applause as it not only traps all the errors, but in the first 4
> cases it reports the offending word being executed.

> Anyone know how the other Forths behave? or suggest better test cases?

Gforth for DOS v0.1beta is a bad example of Gforth, since it was the
only incarnation of Gforth beta which couldn't catch this sort of
errors, due to the DOS extender used. Gforth 0.3 (DOS and Linux) catches
the first four cases, while it exits on the fifth. Changing DROP hurts a
non-inlining Forth too much. bigFORTH answers with "ok" on BadCode,
since drop is just a macro (thus no code with already compiled DROP is
affected, compiling or executing further DROPs is a (catchable) problem,
though). You'd better wipe a larger portion of a real important piece of
code, e.g. KEY or WORD.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Wed, 26 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases


Quote:

>> : BadRes1  9 0 /MOD ;
>> : BadRes2  0 1 1 UM/MOD ;
>> : BadBreak BEGIN  AGAIN ;
>> : BadNumb  1 1 BASE ! . ;
> No problem for Gforth:

> badres1
> :5
> badres1
> ^^^^^^^
> Error: Floating-point unidentified fault

I don't see any floating-point there. No points :-)

Quote:
> badres2   ok
> .s <2> 0 0  ok
> . . 0 0  ok
> .s <0>  ok

Overflow on (hardware) division is truly undefined, so I'd rather have the
exception. If UM/MOD is written in software, please return -1 -1 (or
whatever is umax-int).

Quote:
> badbreak
> :10
> badbreak
> ^^^^^^^^
> Error: User interrupt

Very good. (I assume it was tested under Linux).

Quote:
> badnumb  1  ok

This is good and bad. It doesn't crash, just gives the wrong result,
making it look dangerously OK. What is the value of BASE now? It can't be 1.

-marcel



Fri, 28 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

Hmm.. the way the above named topic comes up reminds me of talking about
some pride of toys (ok, 'real' toys ;) ) capable of shipping around
obstacles by themselves like those other mechanical toys. But the
difference in the picture makes me think about, as far as the obstacle
seems to be meant to be that one who wants to use that stuff. So far, so
conveniant an old song in programmer's world.

Maybe it were nice to have a machine around which would not crash in any
instance (one should add 'hopefully' anyway). But still, it cannot be
built, I am afraid. The example with a secondary redefinition for PICK
and ROLL (be it by loops or by RECURSEs) makes for one way which shows
some limits. Somewhere I saw a 'DISCARD' as well, for the same category
(" 0 ?DO DROP LOOP ").

The argument lying behind gives the description of a strength of the
tool, this is late binding - in the above cases: late binding with
parameters meant to be counters. The next session were late binding with
parameters meaning runtime behaviour in general, by xt's.

To ask if parameters really represent an xt is trivial compared to the
question if those represent a mechanical behaviour which fits the
instance. Anyone who can check if a DUP makes sense, or a DROP - even if
both are allowed, say by " 0 ?DO DUP >R EXECUTE R> LOOP DROP "? This is
a 'DISCARD', when calling it with " ['] DROP ... " and a stack-filler
with " ['] DUP ... ".

Now it may reduce to saying, ok, it can be built (in many regards)
'crash-proof'. But what I missed so far was the hint to admit, it cannot
be said for sure, if it will do anything useful when it is built that
way. Help is given with runtime checks for memory and stack ranges, and
return stack balance (that PICK and ROLL redefinitions can be checked,
but at runtime only). On some few more (hardly much more other than
xt's), there is some re-assurement if a type is reasonable, again at
runtime, since the source of a parameter is rarely only to be assumed to
be known with a stack machine.

The one who _uses_ an implementation can build the most checks by
himself - mainly expected ranges of values, and expected change of stack
depth.

Beyond of those checks, I think, the main thing to have is the tools for
interactive development. So it is not only checking against not
crashing, but checking against if it does what it should. To find a " 0
['] DROP !  " interactively, if the ranges by chance are left as valid
ones, should be enabled to be found nearly as fast, as it takes, when
contemplating in front of a machine how nice this thing were after it
trapped the object of confusion (the user), in terms of a {*filter*}ic
relationship... (some describe it more elegant in terms of AI then).

So, two questions I found associated to this one:

Are the tools efficient? Just for a small example for things to work
fast and smoothly, to find reasons of crashes: What does a de{*filter*} do,
if there occurs a "MARKER FORGET-IT" and later-on, written in the
source, "DEBUG FORGET-IT" (in whatever other idiom)? Will the de{*filter*}
stop because a data structure is encountered, or will it rightly
bring-up the method, show it, allow interpreter use, and after
finishing, continue interpreting the source?

Does this help for recommending Forth? I cannot answer that. But I just
wonder what anyone does when having completed some sources which are
_not_ sources implementing a Forth and are worth more than the effort of
one afternoon. The question arises to me as far as it looks like to be
favourable to support in first instance a Forth interpreter when used as
a calculator or some other object of fun to sit in front of, so to avoid
it to be crashed when used this way. Let me guess that this is not the
first strength of this environment.

**

I have Forth running as a batch language in some instances, and keep a
floating transition between interpreted sources and stand-alone programs
(if it gets too big or but if it is used too often, so it becomes a
program, elsewise maybe sources are interpreted). I wonder in this
context, if ever someone would let things run without having checked
elementary consistencies. (As given the remark above, I expect to need
less time for debugging over-all, than to write it having done major
bottom-up checks).

Anyway, a Forth interpreter showing an 'ok' and waiting for a user may
be a very bad thing if, say, a remote system has to continue after
finishing a Forth job. And a Forth finishing without messaging for
insconsistencies encountered, may be bad the same way - maybe a Forth
environment is just one element in a chain with other tools.

This makes for one more question: Will it co-operate in chained
environments, as well in (at least most, hopefully) situations not
foreseen?



Fri, 28 Jan 2000 03:00:00 GMT  
 Crashproofing - test cases

As the one who started this thread, perhaps I should summarise where
we've got to regarding Crashproofing.  Please let me know if I have
missed anything ...

We were looking for the reasons why a Forth might crash and portable
ways to prevent the crash during development.  6 ways were suggested
together with some test cases.  Tests were also suggested for divide by
zero and out of range, although a Forth which crashes on these has not
been reported.

TEST RESULTS
A number of freely-available Forths were tested to see whether extra
crash-proofing was worthwhile.  The latest results are appended.  An
ideal Forth environment would yield only 0s or -2s.  We don't have any
results for commercial Forths.  Are they better than free ones in this
respect?

BADEXECUTE
Ways to prevent BadReturn and BadExecute were suggested.  The check
which evolved for BadExecute was quite elegant, saving execution tokens
at run-time as generated by ' ['] FIND and SEARCH-WORDLIST and checking
against these before use by EXECUTE CATCH and DEFER.

The systems tested mostly detected BadExecute and recovered gracefully,
so perhaps the elegant solution is not needed after all.

BADCODE
Most of the systems tested failed to recover after code was overwritten.
The transition from 16-bit DOS (with code and data in separate segments)
to 32-bit Forths has weakened most Forths in this respect.  It seems
that overwriting code is the easiest way to crash a modern Forth.
Perhaps we should think about a way to protect against this, especially
for beginners.

Bye for now                                                      
                                         ____/  /  __  /   /   /   /   /
Chris Jakeman                           /      /  /  _/   /   /   /  /
                                       __/    /  / __    /   /   /_/
at Peterborough, a cathedral          /      /  /   /   /   /   /  \
city 80 miles north of London.     __/    __/  ____/    ___/ __/   _\  
Where do you come from?          
                            Forth Interest Group United Kingdom Chapter
Voice +44 (0)1733 753489    at http://www.forth.org/fig/uk/homepage.htm
-----------------------------------------------------------------------
\ CRASH-PROOFING TEST RESULTS - 21-Aug-97

        \ Find a value not likely to be an execution token.
1 ALIGNED CONSTANT NotAnXT        
        \ Find an address likely to be outside the data space.
-4 ALIGNED CONSTANT NotADataAddress  
        \ Find an address which is likely to be unaligned.
HERE ALIGNED 1+ CONSTANT NotAligned
        \ Create a : word which cannot be a macro.
: _DROP   DROP ;

: BadExecute ( -- ) NotAnXT EXECUTE ;


: BadReturn  ( -- ) NotAnXT >R ;
: BadCode    ( -- ) ['] _DROP             \ Find an XT
                    20 0 FILL             \ Overwrite it
                    0 ['] _DROP EXECUTE ; \ Try executing it
: BadRes1    ( -- n1 n2 ) 9 0 /MOD ;      \ Divide by zero
: BadRes2    ( -- ) 0 1 1 UM/MOD ;        \ Out of range
: BadBreak   ( -- u1 u2 ) BEGIN AGAIN ;   \ Try to interrupt loop
: BadNumb    ( -- ) 1 1 BASE ! . ;        \ Loops forever?

\ Result Codes:
\   0 - harmless, no need to detect action
\  -2 - prevents action, reports cause and location, continues at
\       Forth prompt.
\  -3 - prevents action, reports cause only, continues at Forth prompt.
\  -4 - prevents action, reports "Error found", continues at
\       Forth prompt.
\  -6 - executes action, but values returned are incorrect.
\  -7 - prevents action, reports cause only, empties
\       dictionary, continues at Forth prompt.
\ -10 - prevents action, reports cause and location, exits Forth.
\ -11 - prevents action, reports cause only, exits Forth.
\ -12 - prevents action, reports "Error found", exits Forth.
\ -14 - no message, exits Forth.
\ -16 - no message, hangs Forth but computer need not be re-booted.
\ -18 - no message, hangs Forth and computer must be re-booted.
\ -20 - no message, corrupts Forth which hangs at some later time.

\       Bad      Bad      Bad    Bad     Bad   Bad   Bad   Bad    Bad
\       Execute  Address  Align  Return  Code  Res1  Res2  Break  Numb
\
\ F-PC for DOS v3.5 (from Chris Jakeman):
\       -18      0        0      -18     0     -4    -6    -18    -18
\ Win32Forth v3.5:
\       -2       -2       0      -2      -18   -2    -2    -16    -6
\ GForth for Unix v0.3.0 (from Bernd Paysan):
\       -4       -4       0      -4      -16   -3    -6    -3     -6  
\ GForth for Win32 v0.3.0*:
\       -16      -16      0      -16     -16   -16   -6    -16    -6
\ GForth for DOS v0.3.0:
\       -4       -4       0      -4      -18   -3    -6    -3     -6
\ iForth v1.07 Linux (from Marcel Hendrix):
\       -3       -3       0      -3      -20   -3    -3    -11**  -11  
\ mxForth v2.4 Linux (from Marcel Hendrix):
\       -7       -7       0      -7      -20   -7    -7    -11**  -11
\ 4th v3.1d (from Hans Bezemer):
\       -10      -10      0      -10      0    -10   n/a   -16    -10

\ * The Win32 results are much worse than the Unix ones due to a bug in
\   the cygwin32 library, not GForth.

\ ** Under NT it is not possible to achieve -11, but only -14.



Mon, 07 Feb 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

> TEST RESULTS
> A number of freely-available Forths were tested to see whether extra
> crash-proofing was worthwhile.  The latest results are appended.  An
> ideal Forth environment would yield only 0s or -2s.  We don't have any
> results for commercial Forths.  Are they better than free ones in this
> respect?

I thought I've submitted results for bigFORTH. However, bigFORTH for
Linux isn't really commercial, though. Here they are:

\       Bad      Bad      Bad    Bad     Bad   Bad   Bad   Bad    Bad
\       Execute  Address  Align  Return  Code  Res1  Res2  Break  Numb
\ bigForth for Linux (from Bernd Paysan):
\       -3       -3       0      -3      -20   -3    -3    -3     -6  

bigFORTH could even report the locality (from a return stack trace) in
most of the cases, but I haven't ported the error handler so far.

Quote:
> BADCODE
> Most of the systems tested failed to recover after code was overwritten.
> The transition from 16-bit DOS (with code and data in separate segments)
> to 32-bit Forths has weakened most Forths in this respect.  It seems
> that overwriting code is the easiest way to crash a modern Forth.
> Perhaps we should think about a way to protect against this, especially
> for beginners.

Manipulating code or part of code is often vital for Forth systems. E.g.
bigFORTH's PATCH words (a system-wide DEFER) uses an inline number to
jump to, which is patched with IS. Also, variables and code share space,
and code generation in 32 bit Forths certainly uses the same store
primitives as the user can. Modern OS's like Linux could provide a
memory mapped code area, which is made r/w only for compiling, but this
adds unnecessary complexity (separate code and data, remap code for
compiling), and will drastically slow down the compilation process.

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Mon, 07 Feb 2000 03:00:00 GMT  
 Crashproofing - test cases

Quote:

> BADCODE
> Most of the systems tested failed to recover after code was overwritten.
> The transition from 16-bit DOS (with code and data in separate segments)
> to 32-bit Forths has weakened most Forths in this respect.  It seems
> that overwriting code is the easiest way to crash a modern Forth.
> Perhaps we should think about a way to protect against this, especially
> for beginners.

What is tricky about this is that it requires emulating the automatic
protection provided when code and dataspaces are seperated, and code space

        However, if the code is not assuming that code space and dataspace
are mingled, it seems like it should be possible to keep track of which
memory references within the range of the code space are permitted
references, by tracking the state of whether the last value written into
the dictionary was a code-space valid value or a data-space valid value,
and when a state transition occurs storing the address in a table.  The
table should hold a sequence of code and data space spans.  The real

and ! without the system grinding to a halt.  Me, I'm just now starting
the OS textbook that describes Minix, so I'd hand that one over to all of
the pro's in the group.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Tue, 08 Feb 2000 03:00:00 GMT  
 Crashproofing - test cases



Quote:

>> BADCODE
>> Most of the systems tested failed to recover after code was
>> overwritten.  The transition from 16-bit DOS (with code and data in
>> separate segments) to 32-bit Forths has weakened most Forths in this
>> respect.  It seems that overwriting code is the easiest way to crash
>> a modern Forth.  Perhaps we should think about a way to protect
>> against this, especially for beginners.
>What is tricky about this is that it requires emulating the automatic
>protection provided when code and dataspaces are seperated, and code

>    However, if the code is not assuming that code space and
>dataspace are mingled, it seems like it should be possible to keep
>track of which memory references within the range of the code space
>are permitted references, by tracking the state of whether the last
>value written into the dictionary was a code-space valid value or a
>data-space valid value, and when a state transition occurs storing the
>address in a table.  The table should hold a sequence of code and data
>space spans.  The real problem is accessing this table efficiently to


I did that a brute-force inefficient way.  At HERE you have a pointer
to the last previous ALLOTted region, plus a length for the current
region.  Change any transient use of HERE to avoid those two cells.
Whenever you ALLOT more space you first move those two and add to the
length.  When you switch to compiling you save HERE for next time.

You might need another way to handle strings compiled with S" or C" as
they are allotted some special way while compiling and it's extra
trouble to interfere with those compiling words.


list to make sure the address is in data space.  


currently-valid block buffer or file buffer.  Block buffers are
transient, only the latest one is valid on all systems that have them,
but your system might have other valid blocks.  And there are a few
other transient areas, the WORD buffer, the #> buffer, maybe the

any of these.  Since on a single system you know how big a cell is, you
know how many of them you can fit into a transient buffer and how far
into it you can fit them before you get partly out of the buffer, you
could allow that -- but it isn't completely portable.  A 64-bit Forth
with 1-byte chars has only 128 cells in a block.  And the compiled S"
strings are read-only, as are STATE and BLK among the state variables,


lists for cell data and char data, but I handled that with the
data-typing.  It would be better to do it with separate lists, since
that would automatically generate errors when you used ALIGN ALIGNED
wrong.

It could be faster with binary trees to replace the linked lists.  As
it was I had only about a 50-fold slowdown for all the checking put
together.  I'd suggest doing only lazy rebalancing of the trees.  If
someone has a way to hash this I'd be very interested to see it.



Tue, 08 Feb 2000 03:00:00 GMT  
 Crashproofing - test cases


Quote:
> As the one who started this thread, perhaps I should summarise where
> we've got to regarding Crashproofing.  Please let me know if I have
> missed anything ...

This discussion inspired me to upgrade both mxForth and iForth wrt
exceptions.

Quote:
> \       Bad      Bad      Bad    Bad     Bad   Bad   Bad   Bad    Bad
> \       Execute  Address  Align  Return  Code  Res1  Res2  Break  Numb
> \
[..]
> \ mxForth v2.4 Linux (from Marcel Hendrix):
> \       -7       -7       0      -7      -20   -7    -7    -11**  -11

For those who have missed it, mxForth can also be run under Windows
NT 4.0. I've made available a free mxserver server on my homepages:
 http://www.iaehv.nl/users/mhx/
Use mxserver.exe together with mxforth.img.
For Linux you should rename linux.img to mxforth.img and use the
mxforth executable.

You can see below how the different exceptions are handled (for NT).
^Break is not documented. It still leads to an immediate program abort.
mxForth doesn't do COLD after the exception, so the code compiled up till
then is still available.

-marcel
---
FORTH> cd work C:\DFWFORTH\EXAMPLES\MXF2\work ok
FORTH> include crash-proof.frt  ok
FORTH> badexecute
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = 0x4
hardware exception in ``BadNumb''+$FFBD568C
FORTH> badaddress
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = 0x42a8b6
hardware exception in ``BadAddress''+$00000006
FORTH> badalign  ok
FORTH> badreturn
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = 0x4
hardware exception in ``BadNumb''+$FFBD568C
FORTH> badres1
Caught exception 0xc0000094
INTEGER DIVIDE BY ZERO
instruction pointer = 0x424c50
hardware exception in ``/MOD''+$00000004
FORTH> badres2
Caught exception 0xc0000095
INTEGER OVERFLOW
instruction pointer = 0x424c2c
hardware exception in ``UM/MOD''+$00000009
FORTH> badcode
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = 0x42a894
hardware exception in ``_DROP''
FORTH> 1 1 base ! .
1 1 base ! .
^^^^^^^^^^^^
HOLD space overflow / invalid BASE ?
FORTH> decimal  ok



Thu, 10 Feb 2000 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Upper case / Lower case I'm a lost case

2. CASE vs case vs Case...

3. Writing non-intrusive test cases?

4. Test Case Patterns

5. test case generator

6. Writing test cases in Eiffel; XP for Eiffel

7. A test case for the compound variable question...

8. Test Case Attached for regina VALUE() bug

9. Test cases dependencies?

10. looking for gate level test case

11. Defining test-case complexity [Q]

12. Verilog test cases

 

 
Powered by phpBB® Forum Software