Issue 130 in soar: GDS assumptions can be violated to crash Soar

[so...@googlecode.com]

Status: Accepted
Owner: maz...@gmail.com
Labels: Type-Defect Priority-Medium

New issue 130 by maz...@gmail.com: GDS assumptions can be violated to crash
Soar
http://code.google.com/p/soar/issues/detail?id=130

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.

[so...@googlecode.com]

Comment #1 on issue 130 by maz...@gmail.com: GDS assumptions can be

violated to crash Soar
http://code.google.com/p/soar/issues/detail?id=130

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

[so...@googlecode.com]

Comment #2 on issue 130 by maz...@gmail.com: GDS assumptions can be

violated to crash Soar
http://code.google.com/p/soar/issues/detail?id=130

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>)

[so...@googlecode.com]

Comment #3 on issue 130 by maz...@gmail.com: GDS assumptions can be

violated to crash Soar
http://code.google.com/p/soar/issues/detail?id=130

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;
}

[so...@googlecode.com]

Updates:
Status: Fixed

Comment #4 on issue 130 by maz...@gmail.com: GDS assumptions can be

violated to crash Soar
http://code.google.com/p/soar/issues/detail?id=130

(No comment was entered for this change.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings