[erlang-questions] cover.erl issues

[Siri Hansen]

Hi Manuel!

I think the problem is that ets tables are not deleted before the cover
server is unregistered when cover:stop() is called (and cover:stop() does
not wait for the cover server to fully terminate either). This means that
if you call cover:start() directly after cover:stop() then a new cover
server is started, attempting to create new (named) ets tables while the
old ones could still be alive. The probability of this happening increases
with the amount of cover data in the ets tables, since it then will take
longer to delete the tables.

This is a bug in cover. To confirm it you could call ets:delete(Table) for
each ets table just before

unregister(?SERVER)

in cover:main_process_loop/1.

Regards
/siri



2013/3/21 Manuel A. Rubio "Bombadil" <bombadil@REDACTED>

> I forgo inform that the error occurs with R15B02 and R16B.
>
> El 2013-03-21 13:50, Manuel A. Rubio "Bombadil" escribió:
>
>  Hi!
>>
>> I was developing a lot of projects with rebar and, when I put only
>> one app in the apps directory and use eunit and cover, it works well,
>> but when I create several apps in this directory I often see this
>> message:
>>
>>
>> ------------------------------**------------------------------**
>> -----------------------------
>> ERROR: eunit failed while processing
>> /home/manuel/Proyectos/**myproject/apps/app2: {'EXIT',
>>     {{badmatch,
>>          {error,
>>              {badarg,
>>                  [{ets,new,
>>                       [cover_internal_data_table,
>>                        [set,public,named_table,{**
>> write_concurrency,true}]],
>>                       []},
>>                   {cover,init_main,1,[{file,"**
>> cover.erl"},{line,565}]}]}}},
>>      [{rebar_eunit,cover_init,2,[{**file,"src/rebar_eunit.erl"},{**
>> line,445}]},
>>       {rebar_eunit,run_eunit,3,[{**file,"src/rebar_eunit.erl"},{**
>> line,127}]},
>>       {rebar_core,run_modules,4,[{**file,"src/rebar_core.erl"},{**
>> line,405}]},
>>       {rebar_core,execute,5,[{file,"**src/rebar_core.erl"},{line,**
>> 334}]},
>>       {rebar_core,process_dir1,6,[{**file,"src/rebar_core.erl"},{**
>> line,197}]},
>>       {rebar_core,process_each,5,[{**file,"src/rebar_core.erl"},{**
>> line,268}]},
>>       {rebar_core,process_dir1,6,[{**file,"src/rebar_core.erl"},{**
>> line,173}]},
>>       {rebar_core,process_commands,**2,
>>           [{file,"src/rebar_core.erl"},{**line,61}]}]}}
>>
>> ------------------------------**------------------------------**
>> -----------------------------
>>
>> I think that can be due to a race condition, because the eunit
>> execution between apps is continuous... but I'm not sure :-/
>>
>> Any idea?
>>
>> Thanks.
>> Manuel Rubio.
>> ______________________________**_________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130326/f734bacd/attachment.htm>