odd puzzle solved

[Landau, Charles]

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:jsshapiro@earthlink.net]
> Sent:	Sunday, April 05, 1998 4:05 PM
> To:	eros-arch@eros.cis.upenn.edu
> 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?
> 
> 
> 
> shap