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