bug report: ets:select/2 hangs and consumer 100% CPU

Knut Bakke knutbakke@REDACTED
Tue Jul 6 08:58:57 CEST 2010


Version R13B03, R14A


Slogan: "ets:select/2 hangs and consumer 100% CPU"

Very rarely, like 
once very week on a 10 hrs running system pr day doing ets:select about 
10 times a sec, the system locks up in 100% CPU
with ets:select/2 
never returning.
The table is very small, about 100 items, could be  
less.

Observations)
1) If the process with the hanging ets:select/2 is killed, the involved 
table is deleted and rebuild with the exact same content. Applying the 
same ets:select/2, same match spec, will cause a new hanging.
2) By deleting objects, one by one, the hang finally disappears (maybe after 20 objects have been 
deleted).
3) The table is only accessed though ONE erlang process.
4) The table is of type [public, ordered_set]

We have captured one 
situation of a hang, writing out the match specification and dumping the ets table to file, using tab2file.
The problem is reproducible by:
1) {ok,Tab}=ets:file2tab("EtsSelectHang_)20100628.txt").   %% Please let me know and I send the file. too big
2) ets:select(Tab,  
[{{{guard,true,'$1','_','_','_','_','$2','_',undefined},'$9'},  
[{'<','$1',63444947604},{'/=','$2',this}], ['$_']}]).

The problem is resolved by simply deleting all 
objects in the table, making ets:select/2 return immediately. I have not captured the return value.

Could not enclose file needed in 1). To big according to ezmlm

Observations 2)
We have also captured ONE case 
where
ets:select(Tab,Match,1) has returned ALL objects fo the Match. 
It should only return 1 object. Don't know if it's relevant for this 
case. Have no logs on that case.

Thank you.

-knut



      


More information about the erlang-bugs mailing list