GDS assumptions can be violated to crash Soar

[GoogleCodeExporter]

What steps will reproduce the problem?

The following simple example that can crash Soar because it causes a violation 
in an assumption that the GDS makes.   What it does is first create a 
"target-specification" identifier on the top state that points to another 
identifer.  The agent then subgoals and proposes/applies another operator that 
will will augment whatever ID is pointed to by the target.  

learn --on
watch --learn 2

sp {propose-top-operator
   (state <s> ^superstate nil)
-->
   (<s> ^operator <o>)
   (<o> ^name top-operator)
}

sp {apply-create-target-id
   (state <s> ^operator.name top-operator)
-->
   (<s> ^target-id <ts>)
}

sp {propose-substate-test
   (state <s> ^superstate.superstate nil)
-->
   (<s> ^operator.name substate-test)
}

sp {apply*substate-test
   (state <s> ^operator.name substate-test ^superstate.target-id <t-id>)
-->
   (<t-id> ^foo.name weird)
}

The easiest way to recreate the crash is to step four times until a chunk is 
formed and then step four times more.  (It's easy to modify it so that it will 
crash without an init-soar  by adding an additional top-level operator proposal 
so that it subgoals again after the chunk is made.)  This only occurs when 
learning is on.

The problem occurs when it attempts to try to build a GDS after deciding a 
non-context slot that contains a wme whose match level is different than the 
result it is creating.  

Original issue reported on code.google.com by maz...@gmail.com on 9 Jan 2013 at 9:29

[GoogleCodeExporter]

This is a bug that has existed since at least 9.3.1 and probably much earlier.

Original comment by maz...@gmail.com on 9 Jan 2013 at 9:33

[GoogleCodeExporter]

This might be related to some other previous bug reports, most notable issues 
38, 45, 105 (maybe 2, 66 too).

Since this is a long-standing bug and we're putting this on the backburner, 
here are some observations I made about the above example while debugging that 
might help restart this faster when we get back to it:

GDS error is occuring because the id of the wme being created T1 operator O2, 
has an id T1 at level 1, but the instantiation match is at level 2 (where it 
was created).

When deciding the top-level slot, there's 2 wme's in this order
    - Crash case has different values
        - T1 ^operator O4 from apply*weird-prod
        - T2 ^operator O2 from chunk-1*d3*opnochange*1 (this is original chunk, not new one)
    - During the first run, there's only 1
        - T1 ^operator O3 from chunk-1*d3*opnochange*1
    - With learning off, there's also only 1 at both points
        - Before init-soar: (T1 ^operator O3 +) generated by justification-1
        - After: (T1 ^operator O3 +) generated by justification-2

- Chunk_instantiation adds 2 instantiations to newly_created_instantiations has 
2 instantiations. First one is probably chunk, (name generation seemed like it 
failed one time I looked at it, but not another time?)
        - In first run there are two also, but only chunk seems to fire (or at least only its wme gets added which doesn't lead to a gds being created and the crash).  New wme does get support from both instantiations though.

- Another possibility is that the ordering of firing is flipped around or one 
of the firings isn't being inhibitied
    - Maybe b/c name generation failed?
    - Maybe b/c duplicate not detected or incorrectly detected in rete?
    - Inhibition not happening (could be related because of above, or maybe whatever is making it fail the name setting is also not linking the instantiation to new chunk?) 

- Changing rules so justification/chunk is also o-supported eliminates crash.  
Top-level wme must have i-support on level 1 and o-support from level 2.

- When learning off, add_production_to_rete both return with 
REFRACTED_INST_MATCHED.  When learning on, first case return with 
REFRACTED_INST_MATCHED, but second returns duplicate production

By the way, "first case" in the above notes means the first time the subgoal 
writes a result.  Second case is after the agent is init-soared and run again 
with the new chunk from the first run.  Note that this example can be made even 
simpler so it occurs in one run without any redirection through a top state ID:

learn --on
watch --learn 2

sp {i-support
   (state <s> ^superstate nil)
-->
   (<s> ^problem <child>)
}

sp {p*substate
   (state <s> ^superstate.superstate nil)
-->
   (<s> ^operator <o>)
}

sp {o-support
   (state <s> ^operator ^superstate <ss>)
-->
   (<ss> ^problem <child>)

Original comment by maz...@gmail.com on 10 Jan 2013 at 11:24

[GoogleCodeExporter]

Just another note for future debugging...if you disable line 1335 in chunk.cpp, 
the crash goes away.  This may not be a solution, but it might point to an 
issue with the new chunk being  identified as a duplicate which prevents any 
i-supported results from being asserted,.  Since the production has an unbound 
variable on the rhs which will generate a new/unique result, perhaps that means 
it should have its preference asserted?  Maybe the lack of that assertion is 
what leads to the original instantiation to be processed instead, which causes 
the gds failure. 

    if (rete_addition_result!=REFRACTED_INST_MATCHED) 
    {
        /* --- it didn't match, or it was a duplicate production --- */
        /* --- tell the firer it didn't match, so it'll only assert the
        o-supported preferences --- */
        chunk_inst->in_ms = FALSE;
    }

Original comment by maz...@gmail.com on 14 Jan 2013 at 4:45

[GoogleCodeExporter]

Original comment by maz...@gmail.com on 9 Jun 2014 at 1:16

• Changed state: Fixed