kent logo

CO538 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 6 (2011):

Submission reference: IN2035

Hi, While attempting to test the output from the integrate process for q2, I keep getting this error message whenever I try to run the program:

    Running: q2.tbc
    Error at ../../../../../../../modules/course/libsrc/demo_cycles.occ:50
    Program failed, state = e, eflags = 00000000
    q2.tbc exited with error code: 1

I can't figure out what I'm doing wrong to cause this error :(. Thanks.

Editor: the following question has been rolled into this, since the answer is the same.

Hello, I'm doing Q1 and am on the bit about filtering to remove multiples of 5. I've got some code that I think would work, but my program compiles with no warnings (except that keyboard and error aren't used), but when I run it, it displays:

    Error at [file location]:88
    Program failed, state E =, eflags = 00000001
    q1.tbc exited with error code: 1

If the 88 refers to line 88, I don't understand why as line 88 is simply:

    INT input, remainder:

Can you give any reasons why this might occur (I expect the error message means far more to you than it does to me)?

Answer 6:

These look like possible problems with the Transterpreter? Do you get the same problem when running from a University PC in a terminal room?

Please send me, <p.h.welch@kent.ac.uk>, your source code and say what operating system (and version) you are running. Also, what Java (JDK) version do you have (since the jEdit part of the Transterpreter runs on Java)?

Sorry, doing this will identify yourself to me ... but finding bugs that are our fault will do you no harm! Same also, if the bug turns out to be yours!! :)

Added later: solution to the second question, at least, is below.

Thanks for sending your code – it's your fault!   ;)   But also our fault for giving such a terrible run-time error message and pointing to the wrong line number ...

Check out slides 63-64 of Basics – on the IF process. Also, look here in the occam-pi reference wiki.

Unlike in most programming languages, there is no default do-nothing if an IF-condition fails ... so:

    INT x:
      n := 42
        n = 43
	  out.string ("All is well", 0, out!)
      n := 99

causes a crash, since none of the IF-conditions (there is only one above) is true.

There is a proper engineering reason for this language decision. If you want a default do-nothing, you must say so:

    INT n:
      n := 42
        n = 43
	  out.string ("All is well", 0, out!)
      n := 99

Saying so declares that you have programmed to manage all conditions that are necessary for that IF and that no action need be taken if none of them apply. Such an explicit declaration begs to be defended in any code review.

The INMOS team who first developed occam did not have this rule in the language originally. Their first project was writing the occam compiler in occam and, then, an operating system / IDE for a micro-computer (this was 1984). Their code had plenty of implicit do-nothings at the end of IFs. Someone noticed that many bugs were down to omitted tests (that should not have been omitted). Execution passed through such IFs without failing and crashes occured later that were difficult to trace back to the real source.

They changed the language to the present rule for IF-semantics. Now, explicit do-nothings (TRUE-SKIPs) had to be defended and missing tests were found. IFs without explicit do-nothings were either correct or crashed the first time they executed in a state when the missing test should have been present. Because the crashes were at the actual causes of failure, the bugs were easy to detect and fix.

See also Question 2 (2006), Question 70 (2000) and Question 46 (2000).

It may, or may not, be consoling to know that if you had a Linux or Mac OS and could install KRoC successfully, you could compile with the debug flag:

    kroc -d q1.occ

so that when your execution fails, you are told:

    KRoC: error in PROC "filter" in file "q1.occ" line 96
    KRoC: application error, stopped.

which takes you to the line with the offending IF ...

Keywords: if , stop , transterpreter

Referrers: Question 31 (2012)


Question 63 (2010):

Submission reference: IN1959

Having a bit of a problem with the mars assignment. When I read in the values from hazard, I get a runtime error (STOP error):

  SEQ i = 0 FOR 4
    hazard[i] ? h[i]    <--- this line

Any help would be greatly appreciated.

Answer 63:

The hazard array we plug into robot.control indeed has 4 channels. Are you sure your array h has four elements? If it has less, the runtime error you describe must happen.

Keywords: mars , stop

Referrers: Question 31 (2012)


Question 49 (2007):

Submission reference: IN1376

I am currently doing the Cylons assesment and I have encountered the CSUB0 error. Is there any place where I can find what that error means? Or can you explain me the cause of such error?

The error is in the function:

    ...  code omitted

Answer 49:

We're sorry about this low-level error message! It will be changed. CSUB0 is one of the BYTE-codes in the intermediate language generated by the occam-pi compiler and which the Transterpreter interptrets. It is the instruction generated to check that numbers (usually array indices) are within certain bounds. So, it almost always means an array bounds violation.

You pointed in your code snippet to the line on which the run-time system told you contained the error. That line has a reference to an array element. The index in that reference has gone out of bounds – your code has a bug.

As it says at the top of this page, this is not a forum for debugging your code. However ... you might check your min.index function, which return the minimum range and not the index of the minimum range. Also, in your left.to.center function (once you've fixed the above problem), the index will still go out of range if, for instance, your min.index parameter was equal to MID.RAY.

Keywords: cylons , stop , csub0


Question 53 (2006):

Submission reference: IN1023

I keep getting a STOP error when I try to run my animation, it works for about a second or two and then gives me the error. Is this deadlock? I don't remember getting a STOP error when getting deadlock in the classes.

Answer 53:

No, it's not deadlock – that would give you a deadlock error.

Please browse through the questions and answers from "q7" in the keyword index. The best help for this is probably Question 70 (2000), which also tells how to get more information on the line causing the error – unfortunately, you need the Linux occam-pi compiler (kroc) for this (available within your VMWare linux environment).

Keywords: q7 , 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:

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 31 (2012) , 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:

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 31 (2012) , 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:

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 31 (2012) , Question 6 (2011) , Question 53 (2006) , 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:

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)

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:33 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.