Cover compilation breaks running node

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Cover compilation breaks running node

Roger Lipscombe-2
I'm attempting to use ct_run -cover (per
http://erlang.org/doc/apps/common_test/cover_chapter.html) to get
coverage information from an Erlang node.

I've got a coverspec file that looks like this:

{nodes, ['the_server@roger-pc']}.
{incl_dirs_r, ["path/to/_rel/the_server/lib"]}.
{export, "cover.coverdata"}.

...and I'm running it like this (abridged):

ct_run -cover cover.spec -erl_args -pa path/to/_rel/the_server/lib/*/ebin

After a long wait while it cover compiles 900 modules, it finally runs
my CT test, but it fails because the remote node has been screwed up.
I get a bunch of function_clause and badrecord errors and everything's
entirely broken.

The remote node finally gets stuck in a loop continually complaining
about {badarg,[{ets,update_count,[cover_internal_data_table etc...

Does anyone have a working example of getting coverage from a remote
Erlang node while running ct_run?

Potentially related: can I cover-compile the modules ahead of time,
when I build the release (I'm using relx)?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Cover compilation breaks running node

Siri Hansen
First, it is not possible to cover compile to file, so I guess compiling ahead of time is not straight forward. 

How do you start/stop your remote node? I think that specifying the node in the cover spec means that ct tries to start cover on the node when the test starts. I don't think it is clever enough to do the stuff if the node is started later on. Unless you start it with ct_slave:start, which automatically starts cover on any node, no matter if it is specified in the cover spec or not.

When cover is started on a remote node, it loads the same cover compiled beam files as are running on the local node, so if your nodes are running different versions of your release, then you have a potential problem (e.g. function_clause and badrecords). 

From the badarg with the ets table, it seems that you have cover compiled code running on the node without the cover server being running there (guessing the badarg means the table does not exist, that is). Is there any indication of the cover server crashing, or of unloading of cover compiled code failing? 

Does this happen early in the test run, or at the end of it? A problem I often see is that processes crash when cover is stopped. This has to do with code loading and occurs if a process is still running the old (non cover-compiled) code when cover is stopped. To avoid this, the cover_stop flag is added - see Code Coverage Analysis section in the user's guide. I don't know if your problems are in any way related to this though.

So, this was a bunch of more or less related thoughts - don't know if anything may get you on the right track, but if you want to discuss further please let me know.

/siri

man. 3. jun. 2019 kl. 16:06 skrev Roger Lipscombe <[hidden email]>:
I'm attempting to use ct_run -cover (per
http://erlang.org/doc/apps/common_test/cover_chapter.html) to get
coverage information from an Erlang node.

I've got a coverspec file that looks like this:

{nodes, ['the_server@roger-pc']}.
{incl_dirs_r, ["path/to/_rel/the_server/lib"]}.
{export, "cover.coverdata"}.

...and I'm running it like this (abridged):

ct_run -cover cover.spec -erl_args -pa path/to/_rel/the_server/lib/*/ebin

After a long wait while it cover compiles 900 modules, it finally runs
my CT test, but it fails because the remote node has been screwed up.
I get a bunch of function_clause and badrecord errors and everything's
entirely broken.

The remote node finally gets stuck in a loop continually complaining
about {badarg,[{ets,update_count,[cover_internal_data_table etc...

Does anyone have a working example of getting coverage from a remote
Erlang node while running ct_run?

Potentially related: can I cover-compile the modules ahead of time,
when I build the release (I'm using relx)?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Cover compilation breaks running node

Roger Lipscombe-2
On Mon, 3 Jun 2019 at 15:46, Siri Hansen <[hidden email]> wrote:
> First, it is not possible to cover compile to file, so I guess compiling ahead of time is not straight forward.

Feature request for OTP-23? ;-)

> How do you start/stop your remote node?

In this particular case, the node is already running.

> When cover is started on a remote node, it loads the same cover compiled beam files as are running on the local node, so if your nodes are running different versions of your release, then you have a potential problem (e.g. function_clause and badrecords).

The node running ct_run is a separate node and isn't running the
release, per se, but I did use -pa to point ct_run at the release's
files.

It's cover-compiling the source/beam files from the release directory,
which was only just built, so I don't *think* this is the case...
Moreover, one of the affected modules is in the RabbitMQ AMQP client
library, which hasn't changed. Obviously, for efficiency, I should
probably exclude third party dependencies from cover-compilation, but
I'm still poking around and not at that stage yet.

> From the badarg with the ets table, it seems that you have cover compiled code running on the node without the cover server being running there (guessing the badarg means the table does not exist, that is). Is there any indication of the cover server crashing, or of unloading of cover compiled code failing?

I've closed the terminal window; I'll check again later.

> Does this happen early in the test run, or at the end of it? A problem I often see is that processes crash when cover is stopped. This has to do with code loading and occurs if a process is still running the old (non cover-compiled) code when cover is stopped.

The looping thing happens at the end of the test, but the test already
failed because of badrecord, etc., by this point.

> To avoid this, the cover_stop flag is added - see Code Coverage Analysis section in the user's guide.

I'll try this later and report back.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions