Funny behaviour from dets

John Hughes <>
Wed Jun 30 19:01:25 CEST 2010

I'm playing with dets and QuickCheck, and have encountered behaviour that seems strange to me--although I'm not entirely clear on how dets is supposed to behave if the table is modified during a traversal, so I can't say for certain that this is a bug.

Basically, I'm doing a lazy traversal of the table using match_object, and I'm finding that one of the objects in the table is being returned TWICE. To provoke that, I need to do two things:
  a.. insert an element with the same key (after starting the traversal) 
  b.. do an apparently unrelated traversal of the table
I've translated the QuickCheck counterexample into a unit test---which passes---so you can see the weirdness just by reading the code. Here's the test:

test() ->
    % The file dets_table does not exist when we start the test
    % Insert some data... note, 3 objects in the table, our match will
    % traverse 2 objects at a time.
    % Fix the table before starting a match_object traversal. Note that
    % the behaviour is the same whether or not we do this--it's included
    % to show that the problem is not that I failed to fix the table!
    % Start the traversal, returning the first two objects.
    {[{1,0},{2,3}],Cont} = dets:match_object(dets_table,{'$1','$2'},2),
    % Add another object DURING THE TRAVERSAL. Important that it has
    % the SAME KEY as the object not yet traversed.
    % Perform an apparently unrelated traversal of the table.
    [] = dets:match_object(dets_table,{2,2}),
    % Continue the original traversal.
    % WHAT??? How come we get {0,0} twice???
    {[{0,0},{0,0},{0,1}],_} = dets:match_object(Cont),

The insertion and unrelated traversal can also be performed in another process--it makes no difference, the funny behaviour still occurs.

Is this a bug?


More information about the erlang-bugs mailing list