Recent updates change behavior AND cause errors

[GoogleCodeExporter]

To reproduce download the attachment and follow the directions associated
with ticket #62 (http://code.google.com/p/europa-pso/issues/detail?id=62).
 NOTE THAT YOU MIGHT HAVE TO INCREASE THE NUMBER OF STEPS ALLOWED (search
for 2000 in CrewPlanning-Main.cc) TO SEE THE ASSERT (when it occurs seems
to vary depending on the run, which could be a clue)

When I run this, I see two things that are unexpected:

 1.  The solver runs for more iterations than expected.  With EUROPA
revision 5813 (when this was last working as expected), the planner solves
the problem in less than 1200 steps.  Now, it seems to keep going beyond
that, and only stops due to...

 2.  It crashes with an assert failure (after thousands of iterations):

Resource/base/Profile.cc:295: Error:
m_transactionsByTime.find(c->getScope()[existingIndex]) !=
m_transactionsByTime.end() is false

Original issue reported on code.google.com by tristanb...@gmail.com on 29 Oct 2009 at 9:32

[GoogleCodeExporter]

Original comment by tristanb...@gmail.com on 29 Oct 2009 at 9:39

[GoogleCodeExporter]

At least one thing is going wrong here:
The Profile maintains a map, m_constraintsForNotification, to manage passing 
temporal
constraint addition/removal messages to sub-classes.  When it first receives a
message that a constraint is added to(removed from) a temporal variable of a
transaction, it stores that addition(removal) in the map.  When it receives a 
second
addition(removal) on that same constraint with a different index, it knows that 
the
constraint is between the temporal variables of two transactions, and passes on 
the
message.  If it receives a removal message after an addition, it removes the 
message
information from the map.  What's happening to cause at least one problem is 
this:
-Solver activates a token, creating a slave on a resource with temporal 
constraints,
which creates transactions.
-A constraint C is added on a transaction's time variable.
-The addition message is stored in the map.
-The Solver retracts the decision.
-The ResourceTokenRelation is deleted before the temporal variable and 
constraint.
-As a result of this, the removal of the temporal constraint isn't passed along 
to
the Profile.
-Later on, the pointer for the temporal constraint is reallocated by the system 
for a
different temporal constraint that happens to be on the same profile, so the 
Profile
thinks it's already received an addition message for the constraint.

Original comment by miata...@gmail.com on 2 Nov 2009 at 7:03

[GoogleCodeExporter]

This appears to have been fixed in commits 5889, 5890 and 5891.

Original comment by tristanb...@gmail.com on 12 Nov 2009 at 9:23

• Changed state: Verified