See the ticket for a description of the bug and its fix. This fix required a lengthy period of experimentation to find the issue, because initially I could reproduce it only when Parliament was running inside the JVM, but the JVM hid the outward signs of the error and thwarted my efforts to run in a debugger. As a result, I made some "extra" changes along the way:
I added two C++ unit tests to reproduce the issue. The first, DeftLoadTest, simply loads the same sample data that caused the error to begin with. After I deduced what was going on, I added a second, InferenceStressTest, that performs a minimal set of actions that reproduce the issue, without requiring a data file.
I refactored the rule engine in a couple ways. First, I renamed the RulePosition class to RuleAtomSlot, because it took me way too long to remember what "rule position" meant. This renaming carried through a few method, parameter, and variable names as well, so it actually touches quite a lot of code. Second, I changed the RuleVariableBinding and RuleAtomSlot classes to exhibit better encapsulation so that I could reason over the RuleEngine code more easily.
I moved my cross-platform get-env function from Config (which was the only place it was used) to Util (so it can be used in one of the new tests).
I removed the method Rule::bindStatement, which was quite simply not used anywhere.
I removed some deprecated Boost.Build constructs from the C++ unit test Jam file. (This is the file "Parliament/Test/Jamfile", which will doubtless be unintelligible to you. Just take my word for it that this is all for the better and correct, since learning Boost.Build is quite the adventure.)
See the ticket for a description of the bug and its fix. This fix required a lengthy period of experimentation to find the issue, because initially I could reproduce it only when Parliament was running inside the JVM, but the JVM hid the outward signs of the error and thwarted my efforts to run in a debugger. As a result, I made some "extra" changes along the way: