| Author |
Message |
< Erlang bugs mailing list ~ bug report: ets:select/2 hangs and consumer 100% CPU |
| Guest |
 Posted: Tue Jul 06, 2010 6:59 am |
 |
|
|
Guest
|
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
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Jul 06, 2010 3:42 pm |
|
|
|
Guest
|
Knut Bakke wrote:
> 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 hanging is triggered by an ets object with [] as key.
Empty lists are ok as keys, so this is bug. But it only happens in your
case when the 1000th object from the end happens to be the one with
empty list key.
/Sverker, Erlang/OTP Ericsson
________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-bugs-unsubscribe@erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
