Re: Dropping or cleaning a schedule

[Rob Kewley]

Roger M. Burkhart wrote:

> This error message does indicate the possibility of a fairly specific
> problem with an action of type "ActionChanged_c", which gets created only
> in the fairly unusual situation of an action already being processed
> when another one ends up being scheduled at exactly the same time.
> 
> For an error message like this, a stack trace ("bt" command in the gdb
> debugger) provides a great deal of additional information (in this case,
> the actual call to free a schedule or activity when the error occurs).
> Could you please provide a stack trace for this particular message?

Roger:

        Here is a backtrace of my error message:

Starting program: /home/kewler/swarm/battle/battle 
*** event raised for error: InvalidOperation
*** function: _i_Zone_c__freeIVarsComponent_(), file: Zone.m, line: 245
> object being freed by freeIVarsComponent: (0x82d3268: ActionChanged_c)
> was not allocated by allocIVarsComponent: or copyIVarsComponent:
*** execution terminating due to error

Program received signal SIGABRT, Aborted.
0x4009e741 in CharString ()
(gdb) bt
#0  0x4009e741 in CharString ()
#1  0x4010b1fc in CharString ()
#2  0x400cc18d in CharString ()
#3  0x808e396 in _i_Zone_c__freeIVarsComponent_ (self=0x81cc5f8, 
    _cmd=0x817ce68, anObject=0x82d3268) at Zone.m:242
#4  0x8062e7d in _i_Object_s__dropAllocations_ (self=0x82d3268, 
    _cmd=0x817cdc8, componentAlloc=1 '\001') at DefObject.m:209
#5  0x8062990 in _obj_dropAlloc (mapalloc=0xbffff4d8, 
    objectAllocation=1 '\001') at DefObject.m:100
#6  0x8081ed6 in _i_ScheduleIndex_c__mapAllocations_ (self=0x82c87f8, 
    _cmd=0x817ce28, mapalloc=0xbffff4d8) at Schedule.m:930
#7  0x8062cf1 in _i_Object_s__dropAllocations_ (self=0x82c87f8, 
    _cmd=0x8185448, componentAlloc=1 '\001') at DefObject.m:188
#8  0x8081f80 in _i_ScheduleIndex_c__dropAllocations_ (self=0x82c87f8, 
    _cmd=0x817cdc8, componentAlloc=1 '\001') at Schedule.m:940
#9  0x8062990 in _obj_dropAlloc (mapalloc=0xbffff610, 
    objectAllocation=1 '\001') at DefObject.m:100
#10 0x808d1ca in _i_Activity_c__mapAllocations_ (self=0x82c87c0, 
    _cmd=0x81853a8, mapalloc=0xbffff610) at XActivity.m:535
#11 0x808189c in _i_ScheduleActivity_c__mapAllocations_ (self=0x82c87c0, 
    _cmd=0x817ce28, mapalloc=0xbffff610) at Schedule.m:729
#12 0x8062cf1 in _i_Object_s__dropAllocations_ (self=0x82c87c0, 
    _cmd=0x81853b8, componentAlloc=1 '\001') at DefObject.m:188
#13 0x8081953 in _i_ScheduleActivity_c__dropAllocations_
(self=0x82c87c0, 
    _cmd=0x81881b8, componentAlloc=1 '\001') at Schedule.m:750
#14 0x808c7a2 in _i_Activity_c___run_ (self=0x82bbd38, _cmd=0x81881b0)
    at XActivity.m:126
#15 0x808c753 in _i_Activity_c___run_ (self=0x82d23b0, _cmd=0x81881b0)
    at XActivity.m:121
#16 0x808c753 in _i_Activity_c___run_ (self=0x82bb440, _cmd=0x8188190)
    at XActivity.m:121
#17 0x808c5b8 in _i_Activity_c__run (self=0x82bb440, _cmd=0x817e8e4)
    at XActivity.m:67
#18 0x8069407 in _i_GUISwarm__go (self=0x82160c0, _cmd=0x8176984)
    at GUISwarm.m:45
#19 0x804d832 in main (argc=1, argv=0xbffff814) at main.m:21
#20 0x804c80b in _start ()
(gdb) 


>  If there's a systematic bug that you suspect, then showing some
> fragments of code to produce it in a simple and self-contained test case
> is the most useful form of report to get it fixed.  Perhaps you can
> indicate how your own usage differs from what I'm doing in the code below.


I would be happy to do that for you, but I'm afraid I don't understand
enough about what is causing the error to effectivly write a fragment. 
I apologize in advance for a very long winded explanation of the
conditions which produced my error.  If this is useless to you, maybe
you can give me a better hint at what might be causing the error.  I
will then try to recreate it in a simple model useful for debugging.  I
have cut from my model the code segments which produce the error and how
I managed (possibly by chance) to get a work around.

The code below is where in the execution I get an error.  This first
segment from a method in the model swarm produces the error.  However,
as you mentioned, the Action_Changed_c object indicates creating actions
at the same time as the current actions.  This is exactly what I do.

  if (terminate)  {
    ++iterationsDone;

    // terminate and remove activities from  the schedule
    [getCurrentScheduleActivity() terminate];
    [dynSchedule removeAll];

    // if not complete with iterations, reinitialize objects
    if (iterationsDone < iterations) {
      [self reinitialize];    // *** SEE EXCERPT FROM -reinitialize
BELOW ***
      [dynSchedule activateIn: self];   // *** MY ERROR OCCURS WHEN I
EXECUTE
                                        //       THIS LINE.  ALSO, self
IS THE
                                        //       MODEL SWARM.
      // don't terminate yet
      terminate = 0;

    } 

-reinitialize {

   ...

   // Create initial actions for combatants
  [dynSchedule at: getCurrentTime() createActionForEach: combatantList 
                         message: M(move)];
  [dynSchedule at: getCurrentTime() createActionForEach: combatantList 
                         message: M(search)];
  [dynSchedule at: getCurrentTime() + (timeval_t) ENDCHECKINT 
                  createActionTo: self message: M(checkEnd)];    

  ...

}

In the reinitialize module, I create the initial actions for the next
iteration of the battle.  Basically, I start everyone out searching and
moving.  Since I want to start it all now, I schedule it all for
getCurrentTime().  Maybe my use of the macro is causing the problem???

If I have not thoroughly confused you yet, maybe the following will do
the job.  I will show you the change that fixed the error.  The code
below came from the method -move in the combatant object I use to
represent combatants who fight a battle.  Please note that the only
difference is that I took the scheduling of the next move out of the if
(xpos < destx) { brackets.  I would like to keep the scheduling of  the
next move within the brackets in the interest of efficiency.  It makes
no sense to schedule another move for someone who has arrived at his
destination.  However, if I keep the scheduling of the next move within
the brackets, my error occurs.  This is what led me to believe that my
error was produced by a schedule expiring and then being restarted.  The
inefficient scheduling method would guarantee that at the end of the
battle, there would still be actions left on the schedule.  There more
efficient method would make it likely that when all of the combatants on
one side were killed, there would be no more activities left on the
schedule.  In fact, my error could be produced by something entirely
different.  It is also possible that the code change below changed the
stochastic conditions in the model so that the error now does not occur
simply by chance.  (This is unlikely because it has not occurred in a
wide variety of scenarios, and it almost always occurs with the other
version.


THIS VERSION OF -move PRODUCES AN ERROR

// moves combatants in x direction to destination
-move {
  int endOfMap;                 // the end of the map grid
  int x,y;                      // integer coordinates for location
  timeval_t time;               // current simulation clock time

  x = (int)xpos;
  y = (int)ypos;

  if (!deadFlag) {              // if not  dead
    if (xpos < destx) {         // if  have not reached destination

      // convert kilometers per hour to meters per second
      speed = 20 * 0.2777;
      xpos = xpos + speed * MOVESTEP;

      // ensure has not moved past destination
      if (xpos > destx) {
        xpos = destx;
        speed = 0;
       }

      // see if it has moved off map
      endOfMap = [ao getSizeX] * metersPerSquare;
      if ((int) xpos > endOfMap)  {
        printf("%s moved off the map\n", name);
      }

    // schedule the next move for MOVESTEP from now  // *** NOTE THE
POSITION
    time = getCurrentTime();                         //   OF THESE THREE
LINES
    time += (timeval_t) MOVESTEP;                    //   WITHIN THE if
(xpos <
    [dynSchedule at: time createActionTo: self       //   destx) {
brackets ***
                             message: M(move)];       
    }
  } 
  return self;
}


THIS VERSION OF -move FIXES THE ERROR

// moves combatants in x direction to destination
-move {
  int endOfMap;                 // the end of the map grid
  int x,y;                      // integer coordinates for location
  timeval_t time;               // current simulation clock time

  x = (int)xpos;
  y = (int)ypos;

  if (!deadFlag) {              // if not  dead
    if (xpos < destx) {         // if  have not reached destination

      // convert kilometers per hour to meters per second
      speed = 20 * 0.2777;
      xpos = xpos + speed * MOVESTEP;

      // ensure has not moved past destination
      if (xpos > destx) {
        xpos = destx;
        speed = 0;
       }

      // see if it has moved off map
      endOfMap = [ao getSizeX] * metersPerSquare;
      if ((int) xpos > endOfMap)  {
        printf("%s moved off the map\n", name);
      }
    }

    // schedule the next move for MOVESTEP from now
    time = getCurrentTime();                       // *** NOTE THE
POSITION OF THESE
    time += (timeval_t) MOVESTEP;                  //   THREE LINES
OUTSIDE THE
    [dynSchedule at: time createActionTo: self     //   if (xpos <
destx) { brackets
                             message: M(move)];       
  } 
  return self;
}



> Since this is a fairly unusual situation to have the ActionChanged_c
> object in the first place, I'd like to make sure that the logic for
> freeing these components of a schedule is working correctly.  Also,
> are you freeing the schedule or its activation yourself, or just letting
> it run to completion in the swarm where it's activated, and then trying
> to reactivate it somewhere else?  I'd like to understand more about the
> exact situation when this error occurs.

I think my code above answers this question.  I am not sure what you
mean by "freeing" a schedule.  In short, I check for termination
conditions at fixed intervals in my model.  When they are met, I execute
the code which terminated the getCurrentScheduleActivity() .  I  then
dropped all activities from the dynSchedule, added initial activities
for the next iteration, then attempted to reactivate it in the model
swarm.

I hope all of this hot air either reveals where I have done something
wrong or gets you closer to finding a bug in the source code.  If it
does not, I will attempt to re-create the error in a small piece of test
code.  I'm just not sure what to test.

Thanks for all your help.  I am driving on with my work around version. 
It is my desire to better understand swarm that motivates my search for
the cause of the error.

Rob Kewley

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================