Bug with ets? Or feature?

Matthias Lang <>
Sun Apr 16 23:30:25 CEST 2006


Hi,

By default, the ets table is owned by the process which creates it.

When an ets table's owner terminates, the ets table is automatically
destroyed. In your case the shell is the owner. The badmatch kills
the shell process. Try evaluating self() before and after the lookup.

As you predicted, you haven't found a bug. You've discovered a
feature. It's documented, albeit semi-implicitly, in the ETS manpage.

Matthias

----------------------------------------------------------------------

Jérémie Lumbroso writes:
 > Hello,
 > 
 > The following Erlang session demonstrates something I've found:
 > 
 > 29> ets:new(tmp, [set, public]).
 > 17
 > 30> ets:insert(17, {this, is, a, test}).
 > true
 > 31> ets:lookup(17, this).
 > [{this,is,a,test}]
 > 32> [] = ets:lookup(17, this).
 > 
 > =ERROR REPORT==== 16-Apr-2006::22:57:50 ===
 > Error in process <0.70.0> with exit value:
 > {{badmatch,[{this,is,a,test}]},[{erl_
 > eval,expr,3}]}
 > 
 > ** exited: {{badmatch,[{this,is,a,test}]},[{erl_eval,expr,3}]} **
 > 33> ets:lookup(17, this).
 > 
 > =ERROR REPORT==== 16-Apr-2006::22:57:52 ===
 > Error in process <0.76.0> with exit value:
 > {badarg,[{ets,lookup,[17,this]},{erl_
 > eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]}
 > 
 > ** exited: {badarg,[{ets,lookup,[17,this]},
 >                     {erl_eval,do_apply,5},
 >                     {shell,exprs,6},
 >                     {shell,eval_loop,3}]} **
 > 
 > 
 > It seems the bad match (I know it was bad), destroyed the table 17, somehow,
 > as it does not appear in ets:i() anymore after that first error.
 > 
 > I'm pretty certain that this is normal, but I do not see where it is
 > documented—and I'm reporting on the off-chance that it might be a bug.
 > 
 > Regards,
 > 
 > Jérémie Lumbroso



More information about the erlang-questions mailing list