Race condition in dets causes "bad_object" error

[John Hughes]

QuickCheck appears to have turned up the infamous "bad_object" bug in dets, 
by testing for race conditions. This one can be reproduced using the 
attached code as follows:

Erlang R14B (erts-5.8.1) [smp:2:2] [rq:2] [async-threads:0]

Eshell V5.8.1  (abort with ^G)
1> dets_eqc:bug_bad_object().
Failed! Reason:
{'EXIT',{badarg,[{erlang,length,
                         [{error,{{bad_object,read_buckets},"dets_table"}}]},
                 {dets_eqc,corrupted,2},
 ...lots of output...

Prefix:
   open_file(dets_table,[{type,set}]) --> dets_table
   insert(dets_table,[{1,0}]) --> ok

Parallel:
1. lookup(dets_table,0) --> []
   delete(dets_table,1) --> ok

2. open_file(dets_table,[{type,set}]) --> dets_table

Result: ok
false

What's happening is that we first do the prefix above, then the two parallel 
branches (which appear to work, in that the calls return the correct 
results). Finally we reopen the table and call match_object(...,'_'), which 
returns the bad_object error.

This isn't the SAME bug as the one I reported a week ago that causes a 
"premature_eof" error--as well as the R14B version of dets, I've tested a 
fixed version that Hans Bolinder sent me in which the "premature eof" bug 
has been fixed--so there is something else wrong.

John 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dets_eqc.erl
Type: application/octet-stream
Size: 9239 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20101004/14aa602a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pretty.erl
Type: application/octet-stream
Size: 759 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20101004/14aa602a/attachment-0001.obj>