Another test program. In this, the error is now reproducible on wx86cl.exe(Win XP Pro 32bit.)
On Darwin, it typically takes less than 10 seconds to reproduce the error even without the #'clrhash-thread.

(In [15444]) Because of pc_luser_xp()'s expectations/constraints, don't modify %temp0
in .SPset_hash_key_conditional. (This is similar to r15433, and doesn't
fix ticket:993 either, but may have caused another problem.)

My guess is that between set-hash-key-conditional and set-hash-value-conditional in lock-free-puthash,
the partially inserted entry is in DELETED1 state.
If GC happens between set-hash-key-conditional and set-hash-value-conditional and remhash or clrhash has set nhash.vector.deleted-count to 1 since the last GC,
mark_root (in x86-gc.c) deletes the partially inserted entry.

(In [15525]) In lock-free-puthash handle a new key getting relocated just before it's added to the table. Fix %lock-free-rehash-in-place to set both key and value in a free slot. This fixes ticket:993.