| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Functions in this module are never called, and some functions are
outdated. In order to avoid confusion (and need for update), the
module is now reduced to a simple dummy module.
|
|
If a module includes eunit.hrl, a parse transform adds the function
test/0 on line 0 in the module. A bug in OTP-18.0 caused
cover:analyse_to_file/1 to fail to insert cover data in the output
file when line 0 existed in the cover data table. The bug is corrected
by the commit "Fix cover output file".
This commit adds a test which checks that the bug is not introduced
again.
|
|
It is possible that not just the source but even the beam of a module
is not available when calling analyse_to_file.
For example when coverdata is imported from an old file and since then
a module was removed.
Before this fix cover:analyse_to_file/3 could possibly never return
because of a helper process crashed with error:undef and never reply
to the caller.
At the same time link the helper process to cover_server so any
further error won't let the caller waiting indefinitely.
|
|
OTP-8188 introduced a fix for handling last expressions in
expressions like case, try and friends. However the fix did
not account that some of those expressions like receive may
have no clauses (only an after clause), leading to a function
clause error when cover compiling code with such expressions.
|
|
The reconnect/1 test starts another node and takes down the connection
to it for a while. However, it has been in observed in our daily builds
that sometimes a "spontaneous" re-connection occurs.
I think that it because of the call to rpc:cast/3 which internally
will set the group leader for the remote process to a process on
the test_server node. It seems that sometimes the group_leader/2
call will re-establish the connection. Unfortunately, I have not
been able to force this to happen by inserting delays in the rpc
module, so it it still just an hypothesis.
However, letting the other node do the disconnection does seem to fix
the problem and intuitively that should be safer way to do it because
the group_leader/2 call and the disconnection will be executed
sequentially on the same node instead of concurrently from two
different nodes.
|
|
|
|
Cover was rewriting guard clauses as non-remote calls.
That said, if a guard contains erlang:is_binary(Binary),
Cover was incorrectly removing the erlang prefix which
lead to errors if is_binary is not auto imported.
This commit keeps the abstract format as it is.
|
|
Prior to this commit, cover relied on a simple heuristic that
traverses directory from the beam file to find a source file.
The heuristic was maintained with this patch but, if it fails,
it fallbacks to the source value in the module compile info.
In order to illustrate how it works, one of the tests that
could not find its source now passes successfully (showing the
source lookup is more robust).
|
|
OTP-10523
Earlier, if the connection to a remote cover node was lost, all cover
data was lost and the cover_server on the remote node would die. This
would cause problems if there were cover compiled modules that would
still be executed since they would attempt to write to the no longer
existing ets tables belonging to the cover_server.
This commit changes this behavior so that the cover_server on the
remote node will survive connection loss and continue collecting cover
data. If the connection is re-established then the main node will sync
with the remote node again and cover data will not be lost (unless the
node was down).
|
|
Funs are identified by a triple, <Module,Uniq,Index>, where Module is
the module name, Uniq is a 27 bit hash value of some intermediate
representation of the code for the fun, and index is a small integer.
When a fun is loaded, the triple for the fun will be compared to
previously loaded funs. If all elements in the triple in the newly
loaded fun are the same, the newly loaded fun will replace the previous
fun. The idea is that if Uniq are the same, the code for the fun is also
the same.
The problem is that Uniq is only based on the intermediate representation
of the fun itself. If the fun calls local functions in the same module,
Uniq may remain the same even if the behavior of the fun has been changed.
See
http://erlang.org/pipermail/erlang-bugs/2007-June/000368.htlm
for an example.
As a long-term plan to fix this problem, the NewIndex and NewUniq
fields was added to each fun in the R8 release (where NewUniq is the
MD5 of the BEAM code for the module). Unfortunately, it turns
out that the compiler does not assign unique value to NewIndex (if it
isn't tested, it doesn't work), so we cannot use the
<Module,NewUniq,NewIndex> triple as identification.
It would be possible to use <Module,NewUniq,Index>, but that seems
ugly. Therefore, fix the problem by making Uniq more unique by
taking 27 bits from the MD5 for the BEAM code. That only requires
a change to the compiler.
Also update a test case for cover, which now fails because of the
stronger Uniq calculation. (The comment in test case about why the
Pid2 process survived is not correct.)
|
|
|
