Re: [Sks-devel] sks recon crashes with ptree corruption

[Phil Pennock]

On 2012-08-10 at 00:45 -0400, Robert J. Hansen wrote:
> John Clizbe and I have both had a problem recently with sks recon
> crashing in a way that completely borks the PTree/ subdirectory.  If
> your sks recon process dies and, upon restarting it, you see this in the
> log:
> 
> 
> 2012-08-10 00:38:56 Raising Sys.Break -- PTree may be corrupted:
> Failure("remove_from_node: attempt to delete non-existant element from
> prefix tree")
> 2012-08-10 00:38:57 DB closed
> 
> 
> ... then you may join the ranks of those affected by this bug.
> 
> There is no fix yet, nor do we know exactly what's causing this bug to
> manifest.  For now, if your PTree/ subdir gets borked the best way to
> proceed is to rebuild the entire PTree/ subdir:

Since this is new, I suspect the only recent change I know of to how
elements are indexed on disk: my clock resolution fixes, which always
get a unique new time-of-day.

It's _possible_, perhaps, that some piece of logic was depending upon
the key_to_metadata* functions always returning the same time value when
called in quick succession, which might theoretically have been a bug,
but now most definitely would be.

I'm not spotting a link going down the invocation stack meeting
something coming up, so I might be wrong: I might be innocent.

The other change recently would be _what_ is stored on disk: are you
running tip, with the ECDH/ECDSA key support?  Might it be a bug in the
layout of metadata for those keys?

My main suspicion is my change though; I started chasing this a short
while ago, but need to go to bed.

-Phil