Bug with ets? Or feature?

[Matthias Lang]

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