[Oberon] Please, what does it means? And how do deal with this?

Fernando Passold fpassold at das.ufsc.br
Wed Mar 26 03:49:20 CET 2003


Hy people,

Please, I have again an error with Oberon System 3 R 2.3 Compilled.
(I pray thay the new version is most better than this).

During run-time I receive this simple mesage:

XO> Main.StartRobot  ~
...::: Starting robot controlers...

[BEGIN | EXCEPTION]
- Trap kind: Instruction-Fetch from No-Execute Segment
- Task Entry: Shells.ExecutionHandler.Run
- Task Id: 15
- Task Status: Halted
- Trapped Procedure Frame: Robot.Robot.StartController
- Current Instruction Pointer: 008D1D0CH
- Relative PC: 44084
- Stack Dump (Imprecise) Follows:

  Robot.Robot.StartController                                          PC:
44084
    @for                     = 3
    i                        = 4
    robot                    = 100B6EC0H
  Main.StartRobot                                                       PC:
8100
    err                      = 269018688
  Shells.ExecutionHandler.Run                                           PC:
3812
    e                        = 1008E640H
  Tasks.Terminate                                                      PC:
48240

[END | EXCEPTION]


XO>

And, off course this command has stayed as:
  15  "Cmd: Main.StartRobot"                    THREAD  HALTED  normal

For a language/system considered Real-Time this is a problem...
I can not stop this halted command and loose the controll of the
system because some flags indicating wrong information...

The big problem is: what does this menas:
"Trap kind: Instruction-Fetch from No-Execute Segment" ???

Using the option "* \Nnf"of the compiller, I discover that it is
pointing to the statement:
  robot.controlFBTask.Start;
in the middle code of Robot.StartRobot.

This mesage does not help because this error only occours after I change the
controller type of the robot and this only occours with one specifically
type of
controller. Using the others controller this error does not happen.
So... how can I discover the real point of the problem!?

And why Oberon Systems halt real-time tasks when a exception with them
occour? Does it have a way to discover during run-time the real-state of
a task?

thanks in advance,

Fernando Passold
.............................
FeRnando Passold
Doutorando DAS/LAI - UFSC - Florianópolis/SC - BRAZIL




More information about the Oberon mailing list