Re: Dropping or cleaning a schedule

[Roger M. Burkhart]

Rob Kewley writes:

> I am still having some trouble with a dynamic schedule in my model.  I
> can work around it, but something inside me wants to understand how
> schedules and activities work and why I get this error.  If my model's
> dynamic schedule reaches its end and has no more activities left on it,
> I cannot reactivate that schedule for another iteration after adding the
> initial activities to it.  This only works if I stop the schedule while
> I still have activities on it.  Why is this?  Here is the text of the
> error message I got.

Simple reactivation of a schedule should work fine.  I tried to create
a simple case of a dynamic schedule (including AutoDrop as I recall
you're using) and find no problem continuing to use the same schedule
after completing it in one activation and then reactivating it in another.
Sample code of my own test is below.  But these cases typically have more
dependency on exact conditions of a case than your simple description
provides.  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.
(Note: the example uses SwarmProcess instead of Swarm simply because I'm
linking it only with the activity library and not swarmobject, so as to
eliminate any extra complications.)

>Phish:~/swarm/battle$ battle
> *** event raised for error: InvalidOperation
> *** function: _i_Zone_c__freeIVarsComponent_(), file: Zone.m, line: 245
> > object being freed by freeIVarsComponent: (0x82d3648: ActionChanged_c)
> > was not allocated by allocIVarsComponent: or copyIVarsComponent:
> *** execution terminating due to error
> IOT trap/Abort (core dumped)

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?
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.

> Something happens when a schedule reaches its last action (note: this is
> not a repeating schedule) that will not allow me to reactivate it.  I
> tried to trace this error through the swarm source code but became
> hopelessly confused.

You're hardly alone; I get confused by it myself.  Especially for the
dynamic situation, there are lots of special cases to handle when
something changes underneath an already running schedule.  It's worked
in all the cases we've thrown at it so far (with some known limitations
still to be fixed to reschedule a pending schedule that has been reset
to earlier updated time), but if you're making really heavy use of dynamic
schedules you might have run into a case that no one else has yet.  So
let's treat it as a potential bug right now and try to get all the things
we'd normally like to see for a formal bug report (though we don't have
any form or instructions for that set down yet, AFAIK).

Roger Burkhart
--
// code fragments to test reactivation of a dynamic schedule

static void reactivateFunction( id swarm, id dynamicSchedule );
static void terminateFunction( void );

void testDynamicSchedule(void)
{
  id  aZone, controlSchedule, dynamicSchedule;
  id  swarm, swarmActivity;

  aZone = [Zone create: globalZone];
  swarm = [SwarmProcess create: aZone];
  _activity_zone = [Zone create: globalZone];

  dynamicSchedule = [Schedule createBegin: swarm];
  [dynamicSchedule setAutoDrop: 1];
  dynamicSchedule = [dynamicSchedule createEnd];

  controlSchedule = [Schedule create: swarm];
  [controlSchedule at: 2 createActionCall: (func_t)reactivateFunction
                   : swarm : dynamicSchedule];
  [controlSchedule at: 4 createActionCall: terminateFunction];

  swarmActivity = [swarm activate];
  [swarm activate: controlSchedule];
  [swarm activate: dynamicSchedule];

  [dynamicSchedule at: 1 createActionCall: (func_t)printf :
    (id)"first scheduled action performed\n"];

  [swarmActivity run];
}

static void reactivateFunction( id swarm, id dynamicSchedule )
{
  [dynamicSchedule at: 3 createActionCall: (func_t)printf :
    (id)"second scheduled action performed\n"];
  [dynamicSchedule activateIn: swarm];
}

static void terminateFunction( void )
{
  [getTopLevelActivity() terminate];
}


                  ==================================
   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.
                  ==================================