I'm not sure if this is the correct place to post this question, but since 

there doesn't seem to be a developers' list, I thought I'd go ahead and post 

it here.



I believe I've found a bug in sim.engine.Schedule in Mason 12.  Specifically, 

there is a execution path that sets but never unsets the variable inStep:



From Schedule.java:



    public synchronized boolean step(final SimState state)

        {

        inStep = true;

        final double AFTER_SIMULATION = Schedule.AFTER_SIMULATION;  // a 

little faster



        if (time==AFTER_SIMULATION) return false;

        ...

        }



If time is AFTER_SIMULATION, then inStep, which was set to true at the 

beginning of the method, is never set back to false.  This appears to be an 

error, as it causes incorrect behavior in the following situation:



for (i = 0; i < SOME_NUM; i++)

   {

   sim.start();  /* Add events to the schedule.  */

   while(sim.step());

   sim.finish();

   }



When i = 0, the while loop causes the simulation to run until the end of the 

schedule, resulting in time being set to AFTER_SIMULATION and the above 

step() code executing, leaving inStep = true.  Next, sim.finish() and 

sim.start() (via calls to their parent SimState classes' start() and finish() 

methods) result in calls to Schedule's pushToAfterSimulation() and reset() 

methods.  Both of these methods check inStep, which is currently true, and 

set the variable killStep to true as a result.  Now, any attempts to add new 

events to the just-reset schedule fail because the scheduleOnce() method 

checks the variable killStep and does not enqueue new events if killStep is 

true.  Thus, the for loop will not work as expected the second time when i = 

1 because it was not possible to add any events to the schedule.



The fix seems to be straightforward.  Replace



if (time==AFTER_SIMULATION) return false;



with



if (time==AFTER_SIMULATION) 

   {

   inStep = false;

   return false;

   }



I've tested this fix and found no side effects... but that doesn't mean there 

aren't any.



This problem looks like it has been fixed in the CVS version of Schedule.java 

that was posted to this list, but since the new version was identified as 

experimental, I thought I'd mention the bug here, in case others don't want 

to use the new untested version or the new version is rolled back and not 

included in the next stable release.



Nicholas