odd puzzle solved
Wed, 16 Sep 1998 16:49:39 -0700
I ran into related bugs at Tandem. When traversing a ring of keys, I would
do things that might affect the ring. I admit I didn't code this correctly
the first time.
> -----Original Message-----
> From: Jonathan S. Shapiro [SMTP:firstname.lastname@example.org]
> Sent: Sunday, April 05, 1998 4:05 PM
> To: email@example.com
> Subject: odd puzzle solved
> I have just solved (I think) a very puzzling bug that I want to
> document. It took me a good 60 hours to nail down.
> You may or may not find this amusing. I will after I take a break.
> The bug arose in three pieces of code, all of which perform a
> traversal of the ring of keys updating those keys (either rescinding,
> depreparing, or updating to reflect an object relocation).
> In the course of this traversal, it is possible to come across a
> prepared key that is hazarded. If the hazard is a read hazard, than
> the correct value of the slot resides someplace else, and one must
> clear the hazard on the slot before revising the content of the slot.
> Clearing the hazard on a read-hazarded slot, however, may cause it to
> be overwritten with a completely different key. This new key may or
> may not be on the key ring one is traversing. As a result, the slot
> that one is examining may no longer be on the key ring following the
> unhazard operation.
> This was not a problem in KeyKOS, because the only read-hazarded slots
> were the register value slots, which only hold number keys and are
> therefore never associated with a KeyRing. In EROS, capability
> registers are copied into the process structure (in KeyKOS: the DIB),
> and it is therefore possible for an arbitrary prepared object key to
> be read hazarded.
> The solution is to simply restart the traversal after a hazard on such
> a key is cleared.
> Wasn't that obvious?