Soar's run command is a kernel-level command, but internally it anchors on one agent, any agent, to do some kind of bookkeeping that I don't understand. When a client callsKernel.RunAllAgents(), the SML client library picks the first agent out of m_AgentMap and uses that for the anchoring. If an event handler is used to destroy an agent during the run, the kernel maintains its reference to the agent it anchored on and Soar crashes when the deallocated agent is next referenced.
Adding agents surprisingly works fine for the above usage pattern, but removal will cause a crash if you are unlucky and the random agent to be anchored on is the one that is removed. There are probably other commands with the same issue, and I think refactoring the kernel to not require the one agent anchor might be a large task.
A much safer usage pattern is to manage the list of agents in the client code and call RunSelf() on them in a loop. If an agent is destroyed, the client can then stop calling RunSelf() on that agent in the loop.
Another simple fix for this issue that doesn't require re-architecting your application is to simply replace kernel calls that run all agents with agent calls that do the same thing, using agents that you know will never be destroyed. That is, instead of kernel.RunAllAgents(X), do agent.ExecCommandLine("run -d -i p X)", where you are certain that agent is one that will never be removed.
Soar's
runcommand is a kernel-level command, but internally it anchors on one agent, any agent, to do some kind of bookkeeping that I don't understand. When a client callsKernel.RunAllAgents(), the SML client library picks the first agent out ofm_AgentMapand uses that for the anchoring. If an event handler is used to destroy an agent during the run, the kernel maintains its reference to the agent it anchored on and Soar crashes when the deallocated agent is next referenced.Adding agents surprisingly works fine for the above usage pattern, but removal will cause a crash if you are unlucky and the random agent to be anchored on is the one that is removed. There are probably other commands with the same issue, and I think refactoring the kernel to not require the one agent anchor might be a large task.
A much safer usage pattern is to manage the list of agents in the client code and call
RunSelf()on them in a loop. If an agent is destroyed, the client can then stop callingRunSelf()on that agent in the loop.Another simple fix for this issue that doesn't require re-architecting your application is to simply replace kernel calls that run all agents with agent calls that do the same thing, using agents that you know will never be destroyed. That is, instead of
kernel.RunAllAgents(X), doagent.ExecCommandLine("run -d -i p X)", where you are certain thatagentis one that will never be removed.