XML CO631 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for stop

Question 43 (2004):

Hi, what is the general problem if when you go to run an occam program it just crashes ?

Answer 43:

There are a number of probable causes, have a look at the answer to Question 103 (2003) or Question 70 (2000) (and other related questions via the keyword index).

Keywords: stop

Question 9 (2004):

I get this error when I try to run my occam program (it compiles fine without errors):

    KROC: Range error / STOP executed (signal 4)
    KROC: Fatal error code 1, core dumped
    Abort (core dumped)

What does this mean?

Answer 9:

Have a look at the answer to Question 103 (2003).

Keywords: stop

Question 103 (2003):

I have problems with this range error:

    KROC: Range error / STOP executed (signal 4) 
    KROC: Fatal error code 1, core dumped
    Abort (core dumped)    

I have looked at the past Anonymous question pages. But none seem to be the problem. I run my program and it seems to run fine. Occasionally it crashes with the range error above. This normally happens about 10 minutes into running it, however it can sometimes occur just after 10 seconds. I'm not quite sure what else could be the problem as I think that after 10 mins of running the process that it would have excuted all of the code at least once.

Here's the list I found that I have checked against:

• accessing an illegal array index (e.g. negative or too large)
• executing an IF statement all of whose conditions are FALSE
• executing an ALT statement all of whose guards are pre-conditioned and all of which pre-conditions are FALSE
• casting from one numeric type to another, but the number being cast is not in the range of the target type
• receiving a variant of a CASE protocol in a CASE input statement that is not programmed to receive that variant. We are not obliged to cater for all variants of the protocol - but, if we don't, we must know that the omitted variants will not be sent
• executing an explicit STOP

any suggestions of what i could do to elimate this very annoying bug ???

Answer 103:

The biggest clue as to what is going wrong is the fact the timing of the crash varies. At a guess, the error is the result of time manipulation using `+' instead of `PLUS', or other arithmetic involving `time' that does not use non-overflowing operators (TIMES, PLUS and MINUS).

As has been said in other posts, if you want more information on the error, you'll need to run with (run-time) debugging enabled. This is only supported on KRoC/Linux at the moment.

Keywords: range-error , stop

Referrers: Question 9 (2004) , Question 43 (2004)

Question 43 (2003):

Will I be penalised if I use STOP to create a deadlock for Question 4?

Answer 43:

No, but it's not a very nice way of inducing deadlock, and it's not always correct. In the default `error-mode', processes that STOP cause a run-time error and the whole program finishes. In `stop' error-mode (which isn't the default), processes that STOP just die quietly, leaving the rest of the program running. Thus, if you use STOP, you should do it in such a way that the program would deadlock `nicely'.

A quick way of causing local deadlock is to communicate on an unconnected channel, simply:

    CHAN OF INT dummy:
    dummy ! 42                   -- deadlocks here, because there's nothing connected to the other side

Keywords: q4 , stop

Question 30 (2003):

my program keeps aborting when i run it, it shows this ...

    KROC: Range error / STOP executed (signal 11)
    KROC: Fatal error code 1, core dumped
    Abort (core dumped)

what is wrong here?

Answer 30:

This is the result of a run-time error in your occam program. These errors are caused by one of the following:

• executing a STOP
• arithmetic overflow on standard operations
• range error caused by array index out-of-bounds
• range error caused by a replicator's count being less than zero

However, the error doesn't tell you where or exactly what the error is. Post-mortem debugging is available in KRoC, but only for the Linux version at the moment -- you can use `gonzo' for this. Compiling with the `-d' flag will turn on debugging such that when the program crashes, it'll display a more useful error message (including the file-name and line-number where the error occurred).

See also the answer to Question 70 (2000).

Keywords: range-error , stop

Referrers: Question 47 (2003) , Question 72 (2003) , Question 86 (2003)

Question 11 (2002):

I get the following error when running my q4 on raptor, I have got up to part three, please could you give me some idea what this error means and what caused it.

  KROC: Range error / STOP executed (signal 4)
  KROC: Fatal error code 1, core dumped
  Abort (core dumped)

Answer 11:

Please see the answer to Question 70 (2000).

Keywords: range-error , stop

Question 70 (2000):

Once the first draft of my q7 program is compiled and run, it produces this error:

    Philosopher 1 is thinking
    KROC: Range error / STOP executed (signal 4)
    KROC: Fatal error code 1, core dumped
    Abort (core dumped)

I don't know what this means, so I would be grateful if you could point me in the right direction ...

Answer 70:

It means your program crashed. There are several possible causes of this run-time error:

• accessing an illegal array index (e.g. negative or too large);
• executing an IF statement all of whose conditions are FALSE;
• executing an ALT statement all of whose guards are pre-conditioned and all of which pre-conditions are FALSE;
• casting from one numeric type to another, but the number being cast is not in the range of the target type;
• receiving a variant of a CASE protocol in a CASE input statement that is not programmed to receive that variant. We are not obliged to cater for all variants of the protocol - but, if we don't, we must know that the omitted variants will not be sent;
• executing a STOP.

I'm afraid the message you report is all you get from the KRoC/Solaris system. If you compile this with KRoC/Linux using the command:

    kroc -d myfile.occ -lcourse

it will tell you the file name and line number of the offending line. [Note: the "-lcourse" flag above is just to link in the course library - something which is automatic with the Solaris version of the kroc command. The active ingredient of the above command is the "-d" flag.]

Keywords: q7 , range-error , stop

Referrers: Question 43 (2004) , Question 30 (2003) , Question 86 (2003) , Question 11 (2002)

Question 37 (2000):

I'm in the process of doing q4 and I've implemented everything except pairs. It all compiles but, when I run it, it immediately gives me an error:

  Range error / STOP executed (signal 4)
  Fatal error code 1, core dumped
  Abort (core dumped)

First thoughts were that I had used STOP wrong. However, I took it out and still got the same error. I can't work out where I could be going out of range, so I just wondered if you could explain the error message to me so I could work out what part of my code it is refering to.

Answer 37:

The run-time error messages are a bit terse, I'm afraid. The above error message can be caused by at least 4 things:

• execute a STOP;
• try to access an array element that's outside the range of its indices;
• try to cast too large an INT into a BYTE (or a negative etc.);
• all conditions in an IF construct turn out to be FALSE (see slide 4-44 and/or section 4.4 of "An Occam2 Checklist").

It's probably the last one that's your problem ...

Keywords: q4 , range-error , stop

Question 31 (2000):

Can we use the keyword STOP in response to a `q' being pressed in Assignment 2?

Answer 31:

Yes - but KRoC is currently set up to regard STOP as an error, so your program will crash. That's OK but not very nice!

We might change KRoC to handle a STOP differently - occam allows more than one semantics. The default one is the current one - treat it as an error. The (arguably proper) one is that the process executing the STOP just stops, but other processes running in parallel continue.

If we made this change, then simply getting your monitor process to execute a STOP would stop that monitor - but the rest of your network might carry on producing output (depending on how you set it up). That would be wrong.

So, your monitor process needs to do something to block everything else as well (e.g. cause a deadlock). The model answer blocks all of the network, but leaves the monitor running (all it does is go into a state where it black holes all keyboard input). The system is not deadlocked because the monitor is still alive and accepting further input. Nothing more is being produced, though, and keyboard input is consumed but ignored - we have livelock.

Bringing a network to a graceful halt (by causing all its component processes to reach their natural end without triggering deadlock) is hard. The paper in the course book ("Graceful Termination - Graceful Resetting") shows how to do it - it's fairly mechanical but tedious. For this exercise, you would have to make new versions of all the basic cycle processes used from the course library - these new versions would be ready to terminate (i.e. no WHILE TRUEs).

But graceful termination is not required. Just getting the monitor to execute STOP is also not good. Getting the monitor to trigger a deadlock (in response to a `q') is easy and will earn full marks (for this part).

Keywords: q4 , stop

Referrers: Question 13 (2001)