[erlang-bugs] Two bugs in dets

John Hughes john.hughes@REDACTED
Mon Sep 20 18:13:36 CEST 2010


Mea culpa. I had defined a local open_file that just returned T, then 
changed it at the last moment to simplify the mail, but forgot to change the 
calls! :-(

John

----- Original Message ----- 
From: "Ulf Wiger" <ulf.wiger@REDACTED>
To: "John Hughes" <john.hughes@REDACTED>
Cc: <erlang-bugs@REDACTED>
Sent: Monday, September 20, 2010 5:54 PM
Subject: Re: [erlang-bugs] Two bugs in dets


>
> I got the same thing when running your examples, but
> the code requires two minor corrections:
>
> dets:open_file/2 returns {ok, T}, not just T.
>
> BR,
> Ulf W
>
> On 20/09/2010 17:09, John Hughes wrote:
>> I've been using dets as an example for some new QuickCheck features, and
>> seem to have discovered a couple of race conditions.
>>
>> Firstly, insert_new is documented as returning a bool, but under certain
>> circumstances it can return ok instead. This code prints ok every time
>> on my machine (R14B under Windows):
>>
>> bug1() ->
>> T = dets:open_file(dets_table,[{type,bag}]),
>> spawn(fun()->dets:insert(T,[]) end),
>> spawn(fun()->io:format("~p\n",[dets:insert_new(T,[])]) end).
>>
>> Both spawns are necessary to make this happen--otherwise the output is
>> true, as it should be.
>>
>> Secondly, the following code causes a bug message to appear:
>>
>> bug3() ->
>> file:delete(dets_table),
>> T = dets:open_file(dets_table,[{type,set}]),
>> spawn(fun() -> dets:delete(T,0) end),
>> spawn(fun() -> dets:insert_new(T,{0,0}) end),
>> ok.
>>
>> When I run this with DETS_DEBUG set, I see this output:
>>
>> 87> dets_bugs:bug3().
>>
>> =ERROR REPORT==== 20-Sep-2010::16:54:35 ===
>> ** dets: Bug was found when accessing table dets_table,
>> ** dets: operation was {delete_key,[0]} and reply was
>> {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{1,insert_new}],[],[],set,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}.
>>
>> ** dets: Stacktrace:
>> [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}]
>> ok
>>
>> I've seen the same behaviour for sets and bags, and when the delete is
>> replaced by an insert (although that's a little harder to provoke).
>> Sample output from a QuickCheck run that shows the latter case is below
>> (but it looks like the same bug).
>>
>> I'm attaching the QuickCheck spec that found these race conditions
>> also--I can provide the right version of QuickCheck to run it and a
>> trial licence if desired. It just focusses on the subset of operations
>> in these examples, and its pretty good at finding a variety of
>> variations on the theme.
>>
>> 6> eqc:check(dets_eqc:prop_parallel(),eqc:counterexample()).
>>
>> =INFO REPORT==== 20-Sep-2010::17:01:59 ===
>> ** dets: (debug) using disk map for dets_table
>>
>> =INFO REPORT==== 20-Sep-2010::17:01:59 ===
>> ** dets: (debug) using disk map for dets_table
>>
>> =ERROR REPORT==== 20-Sep-2010::17:01:59 ===
>> ** dets: Bug was found when accessing table dets_table,
>> ** dets: operation was {insert,[]} and reply was
>> {'EXIT',{function_clause,[{dets_v9,eval_key1,[[{0,insert_new}],[],[],bag,{0,0},[],[],0,[]]},{dets_v9,eval_key,9},{dets_v9,eval_slot,9},{dets_v9,eval_bucket_keys,8},{dets_v9,read_buckets,11},{dets,update_cache,2},{dets,stream_end,5},{dets,do_apply_op,4}]}}.
>>
>> ** dets: Stacktrace:
>> [{dets,stream_end,5},{dets,do_apply_op,4},{proc_lib,init_p_do_apply,3}]
>> Failed! Reason:
>> {'EXIT',{timeout,1000}}
>> 100
>> {[{set,{var,1},{call,dets_eqc,open_file,[dets_table,[{type,bag}]]}}],
>> [[{set,{var,17},{call,dets,insert_new,[{var,1},{0,0}]}}],
>> [{set,{var,19},{call,dets,insert,[{var,1},[]]}}]]}
>> false
>> 7>
>> =ERROR REPORT==== 20-Sep-2010::17:02:00 ===
>> Error in process <0.14925.0> with exit value:
>> {badarg,[{dets,insert_new,[dets_table,{0,0}]},{eqc_run_parallel_commands,run_child,3}]}
>>
>>
>> John
>>
>>
>>
>>
>> ________________________________________________________________
>> erlang-bugs (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>
>
> -- 
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>
>
> 



More information about the erlang-bugs mailing list