I ran into something that took me a while to track down, and I want to see if anyone else has any input on solving it. I found this problem in 6M62, but the underlying issue still seems to apply in 10.1.2.
I’ve created a relation along the lines of:
Particularity relates (relations of things) to each other in groups.
and a phrase along the lines of:
To frobulate (R - relation of values of kind K to values of kind L) ...:
...
let targets be the list of relations of Ks to Ls that relate to R by the particularity relation;
...
The targets list was only being built correctly in a non-deterministic manner. I finally traced the problem to the way that the frobulate phrase was being translated into I6:
tmp_0 = I7SFRAME; ! R argument
BlkValueCopy(tmp_0, RelationTest(Rel_Record_77, RELS_LOOKUP_ALL_Y, BlkValueCopy((I7SFRAME+WORDSIZE), t_0), (I7SFRAME+WORDSIZE*2))); ! builds list
It turns out that the phrase is doing a “pass by value” for the input relation and is setting up a copy of it on the heap. As a consequence, there is a problem due to the way that the HASH_KOV task is handled for relations:
[ RELATION_TY_Support task arg1 arg2 arg3;
switch(task) {
...
HASH_KOVS: return arg1;
...
}
...
];
When the RELS_LOOKUP_ALL_Y task requests a hash value for the relation R, it uses the memory address of the short block, and this is echoed back without modification by the HASH_KOVS task. When a pass by value has occurred while setting up R, the memory address held by tmp_0 will be somewhere on the heap and bear no relation to the address of the source relation R’s “home address” (i.e. its Rel_Record_NN address).