<div class="gmail_quote">On 14 July 2011 10:36, Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker@erix.ericsson.se">sverker@erix.ericsson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I have to confess...<br>
<br>
ets:first is not supposed to behave like that, returning already deleted keys,<br>
even if the table is fixated. You can of course have a race with a deleting process,<br>
but the key should have existed in the table some time during the execution of ets:first().<br>
<br>
I think you suffer from this bug, fixed in R13B01:<br>
<br>
<a href="http://www.erlang.org/download/otp_src_R13B01.readme" target="_blank">http://www.erlang.org/<u></u>download/otp_src_R13B01.readme</a><u></u>:<br>
<br>
   OTP-8040  Various fixes in ETS: ets:first could return a deleted key in<br>
              a fixated table. ets:lookup could return objects out of order<br>
              if a deleted object was re-inserted into a fixed bag.<br>
              ets:delete_object could fail to delete duplicate objects in a<br>
              duplicate_bag.<br>
<br>
<br>
The irony being that you probably wouldn't had found the bug of<br>
the leaking ets:safe_fixtable now if ets:first had behaved like it should.<br>
<br>
Leaking ets:safe_fixtable can be a nasty thing as it might result in gradual performance degradation,<br>
both memory and cpu wise. Deleted objects are not deallocated and the table is not allowed<br>
to adjust its size (rehash) until it is "unfixated".<br>
<br></blockquote><div class="h5"><br>Yes, you are right about this. The reason I stumbled upon this was because the erlang node was gradually eating up all available memory and crashing. I could find no obvious culprit, until I came across this!<br>

<br>Chandru<br><br>
<br>
<br>
Chandru wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the record, I've found out what was causing this.<br>
<br>
A process was regularly executing ets:safe_fixtable(true) on this table, and<br>
not finishing off with ets:safe_fixtable(false).<br>
<br>
This meant that the behaviour of mnesia:dirty_first was affected, and was<br>
also causing increased memory consumption.<br>
<br>
Thanks to Håkan and Sverker for helping me find the root cause.<br>
<br>
cheers<br>
Chandru<br>
<br>
On 1 July 2011 14:44, Chandru <<a href="mailto:chandrashekhar.mullaparthi@gmail.com" target="_blank">chandrashekhar.mullaparthi@gmail.com</a>> wrote:<br>
<br>
  <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
One of my production nodes running R12B-5 is exhibiting some strange<br>
behaviour.<br>
<br>
mnesia:dirty_read(gtp_tid, mnesia:dirty_first(gtp_tid)).<br>
<br>
gives me an empty list. The table has 39K entries. How do I find out what<br>
is happening? I tried using ets operations directly and get the same result<br>
(which is what mnesia is doing behind the scenes anyway). I get the same<br>
empty result using a transaction to read. Any clues?<br>
<br>
96> ets:info(gtp_tid).<br>
[{memory,213857900},<br>
 {owner,<0.741.0>},<br>
 {name,gtp_tid},<br>
 {size,39088},<br>
 {node,node@server},<br>
 {named_table,true},<br>
 {type,set},<br>
 {keypos,2},<br>
 {protection,public}]<br>
<br>
The same operation works ok on other tables.<br>
<br>
cheers<br>
Chandru<br>
<br>
<br>
    <br>
</blockquote>
<br>
  <br>
</blockquote>
<br>
<br>
</div><br></div><br>