Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #19419 > unrolled thread

Forced exit from an infinite loop? (Win32Forth / eForth)

Back to article view | Back to comp.lang.forth

Contents

  Forced exit from an infinite loop?  (Win32Forth / eForth) AKE <assadebrahim2000@gmail.com> - 2013-02-04 04:36 -0800
    Re: Forced exit from an infinite loop?  (Win32Forth / eForth) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-04 14:17 +0000
      Re: Forced exit from an infinite loop?  (Win32Forth / eForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 16:11 +0000
      Re: Forced exit from an infinite loop?  (Win32Forth / eForth) Andy Valencia <user@vsta.org> - 2013-02-04 17:06 +0000
        Re: Forced exit from an infinite loop?  (Win32Forth / eForth) Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 19:53 +0100
        Re: Forced exit from an infinite loop?  (Win32Forth / eForth) Andy Valencia <user@vsta.org> - 2013-02-05 01:00 +0000
        Re: Forced exit from an infinite loop?  (Win32Forth / eForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-05 15:26 +0000
    Re: Forced exit from an infinite loop? (Win32Forth / eForth) Mark Wills <forthfreak@gmail.com> - 2013-02-04 07:32 -0800
      Re: Forced exit from an infinite loop? (Win32Forth / eForth) Coos Haak <chforth@hccnet.nl> - 2013-02-04 21:05 +0100
        Re: Forced exit from an infinite loop? (Win32Forth / eForth) Alex McDonald <blog@rivadpm.com> - 2013-02-04 12:32 -0800
        Re: Forced exit from an infinite loop? (Win32Forth / eForth) "Elizabeth D. Rather" <erather@forth.com> - 2013-02-04 11:24 -1000
          Re: Forced exit from an infinite loop? (Win32Forth / eForth) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-05 18:01 +0000
    Re: Forced exit from an infinite loop?  (Win32Forth / eForth) "Ed" <invalid@nospam.com> - 2013-02-05 10:44 +1100
      Re: Forced exit from an infinite loop? (Win32Forth / eForth) Mark Wills <forthfreak@gmail.com> - 2013-02-04 23:09 -0800
      Re: Forced exit from an infinite loop?  (Win32Forth / eForth) AKE <assadebrahim2000@gmail.com> - 2013-02-05 05:06 -0800

#19419 — Forced exit from an infinite loop? (Win32Forth / eForth)

Hi

Apologise for this basic question.

Is there a way to force a Forth that is stuck in an infinite loop to abort and return to taking commands at the console?

Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing the process and starting it again.

Thanks,

[toc] | [next] | [standalone]

#19421

In article <08b7f96d-f522-4b7b-87e9-109c92e06597@googlegroups.com>,
AKE  <assadebrahim2000@gmail.com> wrote:
>Hi
>
>Apologise for this basic question.

You say basic, I say fundamental.

>
>Is there a way to force a Forth that is stuck in an infinite loop to
>abort and return to taking commands at the console?
>
>Haven't been able to find a way for Win32Forth or eForth -- other than,
>of course, killing the process and starting it again.

This is a quality of implementation issue.
gForth allows to type ^C and you're back in the interpreter with a backtrace.

Version 4 of lina 32 bit had this too (after REQUIRE DO-DEBUG and without the
nice backtrace ), but I haven't yet managed to get this running in 64 bit
versions.

Win32Forth is very large. There may be a facility hidden somewhere.

>
>Thanks,

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#19425

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>Is there a way to force a Forth that is stuck in an infinite loop to
>>abort and return to taking commands at the console?
>>
>>Haven't been able to find a way for Win32Forth or eForth -- other than,
>>of course, killing the process and starting it again.
>
>This is a quality of implementation issue.
>gForth allows to type ^C and you're back in the interpreter with a backtrace.

While it is a quality-of-implementation issue, there is a standard
throw code for "User Interrupt", which I take as a suggestion that a
full-featured system should turn a user interrupt (SIGINT in a POSIX
system, generated by Ctrl-C at a normally configured terminal) into
this Forth exception and let the Forth system deal with it; and if the
exception is not caught by the application, the Forth system should
print an appropriate message and continue in the Forth command line,
if the application was started from the Forth command line (OTOH, if
the application was started from the OS command line, I find it
inappropriate and annoying to fall back into the Forth command line).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#19428

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> ... there is a standard
> throw code for "User Interrupt", which I take as a suggestion that a
> full-featured system should turn a user interrupt (SIGINT in a POSIX
> system, generated by Ctrl-C at a normally configured terminal) into
> this Forth exception and let the Forth system deal with it; and if the
> exception is not caught by the application, the Forth system should
> print an appropriate message and continue in the Forth command line,

The classic problem is somebody interrupts during compilation, and the
system's updating something critical like the word dictionary when you jump
back out to the prompt.  So you (the Forth implementer) need to identify
critical sections in your code to make sure such sections complete before
dispatching the asynchronous event.  Typically in C based Forth's the rule is
that everything involving critical sections is written in C, and Forth
interpreter interrupts only happen when you get back to the Forth level.
In a Forth system which uses Forth all the way down to the CODE words,
you'll need a similar sort of protection, but I'm not aware of any model
"pure Forth" systems which offer an example.  ForthOS had a limited
handling for such interrupts, but was not at all comprehensive.

Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#19429

Andy Valencia wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> ... there is a standard
>> throw code for "User Interrupt", which I take as a suggestion that a
>> full-featured system should turn a user interrupt (SIGINT in a POSIX
>> system, generated by Ctrl-C at a normally configured terminal) into
>> this Forth exception and let the Forth system deal with it; and if
>> the exception is not caught by the application, the Forth system
>> should print an appropriate message and continue in the Forth command
>> line,
> 
> The classic problem is somebody interrupts during compilation, and the
> system's updating something critical like the word dictionary when you
> jump
> back out to the prompt.  So you (the Forth implementer) need to
> identify critical sections in your code to make sure such sections
> complete before
> dispatching the asynchronous event.

Yes, maybe for a 100% solution.  The 99% solution is just to go back to 
the prompt, and hope everything goes well.  We do that on any kind of 
exception, and the others, like segfaults, are much more likely to leave 
the system in a bad state.

The point of ^C-ing a program that has gone wild is to have a chance to 
analyze why.  It's not to have a 100% secure method to terminate it.  If 
it fails, so what?  You have tried at least.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#19436

Bernd Paysan <bernd.paysan@gmx.de> writes:
> The point of ^C-ing a program that has gone wild is to have a chance to 
> analyze why.  It's not to have a 100% secure method to terminate it.  If 
> it fails, so what?  You have tried at least.

Mostly, it will work and save you time in debugging.  Eventually, it will
waste your time because you think you're debugging your own problem but
instead you're debugging your subtly hosed system.  And at least once
it will seriously f*ck you by putting something corrupt into a place where
it will be hard to realize what it's done and harder to undo once you find
out.  For me it was the block cache....

Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#19475

Andy Valencia <user@vsta.org> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> ... there is a standard
>> throw code for "User Interrupt", which I take as a suggestion that a
>> full-featured system should turn a user interrupt (SIGINT in a POSIX
>> system, generated by Ctrl-C at a normally configured terminal) into
>> this Forth exception and let the Forth system deal with it; and if the
>> exception is not caught by the application, the Forth system should
>> print an appropriate message and continue in the Forth command line,
>
>The classic problem is somebody interrupts during compilation, and the
>system's updating something critical like the word dictionary when you jump
>back out to the prompt.  So you (the Forth implementer) need to identify
>critical sections in your code to make sure such sections complete before
>dispatching the asynchronous event.  Typically in C based Forth's the rule is
>that everything involving critical sections is written in C, and Forth
>interpreter interrupts only happen when you get back to the Forth level.

Gforth does not do this kind of protection, and since it is more
protective than most, I doubt that others do it, either.

However, we do a different kind of protection.  In many cases, we
CATCH the exception if it could lead to problems (e.g., if there is a
temporary change of global state, e.g., of BASE) and perform the
appropriate recovery action (e.g., restoring BASE to the previous
value) before THROWing the exception onwards.

In other cases, the problem can often be avoided by having a
committing store.  E.g., for the problem you mention of defining a
word in the dictionary, one can perform the REVEAL at the end (hmm,
looking at CREATE, this does not happen for CREATE, CONSTANT and
VALUE; it does for ";", though).

REVEAL itself deals with linked lists, where it is easy to commit the
insertion of a new element with a single "!"; there are two potential
problems in connection with hash tables, though:

1) Each word is inserted in two linked lists, so it might end up on
one list, but not on the other.  This would be confusing, because the
hash-table linked list is used for searching, while the classical
Forth linked list is used by WORDS.  Also, after later rehashing, the
word might appear in the hash table or disappear from it (but the
state would be consistent then).

2) It's not clear to me what happens if an exception occurs during
rehashing, probably an incomplete hash-table.  Should be easy to spot,
though.

Oh, BTW, these things are all on the Forth level, so delaying
exceptions until the Forth level would not help (and would be a pretty
expensive feature).

Despite having less protection against such things than would be
relatively easily possible, I have not yet experienced such problems
nor heard about them.  Given that one can easily have system
corruption from, say, a buggy use of "!", Forth users should be
prepared to restart the system when things look fishy, and investing a
lot of work into proofing it against the kinds of effects you pointed
out is probably not a good use of resources.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#19423 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

On Feb 4, 12:36 pm, AKE <assadebrahim2...@gmail.com> wrote:
> Hi
>
> Apologise for this basic question.
>
> Is there a way to force a Forth that is stuck in an infinite loop to abort and return to taking commands at the console?
>
> Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing the process and starting it again.
>
> Thanks,

See if your systems supports the word TERMINAL?

For example:

: forever begin 1000 random . terminal? if exit then again ;

[toc] | [prev] | [next] | [standalone]

#19431 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

Op Mon, 4 Feb 2013 07:32:36 -0800 (PST) schreef Mark Wills:

> On Feb 4, 12:36 pm, AKE <assadebrahim2...@gmail.com> wrote:
>> Hi
>>
>> Apologise for this basic question.
>>
>> Is there a way to force a Forth that is stuck in an infinite loop to abort and return to taking commands at the console?
>>
>> Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing the process and starting it again.
>>
>> Thanks,
> 
> See if your systems supports the word TERMINAL?
> 
> For example:
> 
>: forever begin 1000 random . terminal? if exit then again ;

A modern Forth would use KEY? Like Win32Forth.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#19432 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

On Feb 4, 8:05 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> Op Mon, 4 Feb 2013 07:32:36 -0800 (PST) schreef Mark Wills:
>
>
>
>
>
>
>
>
>
> > On Feb 4, 12:36 pm, AKE <assadebrahim2...@gmail.com> wrote:
> >> Hi
>
> >> Apologise for this basic question.
>
> >> Is there a way to force a Forth that is stuck in an infinite loop to abort and return to taking commands at the console?
>
> >> Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing the process and starting it again.
>
> >> Thanks,
>
> > See if your systems supports the word TERMINAL?
>
> > For example:
>
> >: forever begin 1000 random . terminal? if exit then again ;
>
> A modern Forth would use KEY? Like Win32Forth.
>
> --
> Coos
>
> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html

That's about the only way. For a command line window ^C runs in a
seperate process with a different stack; communication through the
stack with a throw is very difficult. For a Window'ed app, ^C is eaten
by the OS and doesn't appear in the key stream.

[toc] | [prev] | [next] | [standalone]

#19433 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

On 2/4/13 10:05 AM, Coos Haak wrote:
> Op Mon, 4 Feb 2013 07:32:36 -0800 (PST) schreef Mark Wills:
>
>> On Feb 4, 12:36 pm, AKE <assadebrahim2...@gmail.com> wrote:
>>> Hi
>>>
>>> Apologise for this basic question.
>>>
>>> Is there a way to force a Forth that is stuck in an infinite loop to abort and return to taking commands at the console?
>>>
>>> Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing the process and starting it again.
>>>
>>> Thanks,
>>
>> See if your systems supports the word TERMINAL?
>>
>> For example:
>>
>> : forever begin 1000 random . terminal? if exit then again ;
>
> A modern Forth would use KEY? Like Win32Forth.

That's certainly a way to incorporate a *planned* optional exit, but the 
OP is talking about a runaway due to a bug. As Alex points out, ^C is 
the appropriate remedy in Windows Forths. That can get you out of a lot 
of things, but there are always possible bugs that can cause such 
wreckage that even a very robust system cannot recover!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19476 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

In article <4rWdne6bC4OYuo3MnZ2dnUVZ_u-dnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 2/4/13 10:05 AM, Coos Haak wrote:
>> Op Mon, 4 Feb 2013 07:32:36 -0800 (PST) schreef Mark Wills:
>>
>>> On Feb 4, 12:36 pm, AKE <assadebrahim2...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> Apologise for this basic question.
>>>>
>>>> Is there a way to force a Forth that is stuck in an infinite loop to
>abort and return to taking commands at the console?
>>>>
>>>> Haven't been able to find a way for Win32Forth or eForth -- other
>than, of course, killing the process and starting it again.
>>>>
>>>> Thanks,
>>>
>>> See if your systems supports the word TERMINAL?
>>>
>>> For example:
>>>
>>> : forever begin 1000 random . terminal? if exit then again ;
>>
>> A modern Forth would use KEY? Like Win32Forth.
>
>That's certainly a way to incorporate a *planned* optional exit, but the
>OP is talking about a runaway due to a bug. As Alex points out, ^C is
>the appropriate remedy in Windows Forths. That can get you out of a lot
>of things, but there are always possible bugs that can cause such
>wreckage that even a very robust system cannot recover!

And then the situation with editors. I have a full screen editor
in my Forth and ^C goes 8 lines down (Wordstar wise).
This is accomplished by setting the terminal in raw mode.
You will have a hard time to recover if the editor is faulty.
(Same with X-windows system if the input goes bezerk.)

>
>Cheers,
>Elizabeth

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#19435

AKE wrote:
> Hi
>
> Apologise for this basic question.
>
> Is there a way to force a Forth that is stuck in an infinite loop to abort and return to
> taking commands at the console?
>
> Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing
> the process and starting it again.

If you're debugging I see no problem.  Getting into an infinite loop
is an error on your part and getting out of it is your punishment!
As Elizabeth said there's a likelihood that whatever caused your
infinite loop has trashed something important.  The safest way
to recover is to reboot forth (and sometimes the entire system).
That said, infinite loop errors don't occur frequently and you know
when they happen.  The errors I worry about are the one's which
return "ok" :)

[toc] | [prev] | [next] | [standalone]

#19443 — Re: Forced exit from an infinite loop? (Win32Forth / eForth)

On Feb 4, 11:44 pm, "Ed" <inva...@nospam.com> wrote:
> AKE wrote:
> > Hi
>
> > Apologise for this basic question.
>
> > Is there a way to force a Forth that is stuck in an infinite loop to abort and return to
> > taking commands at the console?
>
> > Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing
> > the process and starting it again.
>
> If you're debugging I see no problem.  Getting into an infinite loop
> is an error on your part and getting out of it is your punishment!
> As Elizabeth said there's a likelihood that whatever caused your
> infinite loop has trashed something important.  The safest way
> to recover is to reboot forth (and sometimes the entire system).
> That said, infinite loop errors don't occur frequently and you know
> when they happen.  The errors I worry about are the one's which
> return "ok" :)

Exactly right. It means the routine/word that you are working on is
not fully debugged yet. So add some code to the word to read the
keyboard in the loop and exit if you press X or whatever. Unless your
machine has *completely* crashed, that's all you should need to do.

[toc] | [prev] | [next] | [standalone]

#19456

On Monday, February 4, 2013 11:44:17 PM UTC, Ed wrote:

>
> > Haven't been able to find a way for Win32Forth or eForth -- other than, of course, killing 
> > the process and starting it again. 
> 
> 
> If you're debugging I see no problem.  Getting into an infinite loop
> is an error on your part and getting out of it is your punishment!
> As Elizabeth said there's a likelihood that whatever caused your
> infinite loop has trashed something important.  The safest way
> to recover is to reboot forth (and sometimes the entire system).
> That said, infinite loop errors don't occur frequently and you know
> when they happen.  The errors I worry about are the one's which
> return "ok" :)

Well said.  I agree.  

Just to be clear, the intent behind the question was simply to know whether there was some easy mechanism that I had missed.  

I can see from the various responses that the dynamic nature of Forth "under the hood" makes something like this much more complicated than simply interrupting a runaway process, and the resulting complexity makes it a dubious feature.

In fact I agree with all who have expressed that there is no real need for this 'feature'.  The interactive nature of Forth makes debugging quite easy.  It also makes it easy to write / run test cases.

This also means it is not such a big problem to kill Forth and restart.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web