aboutsummaryrefslogtreecommitdiffstats
path: root/lib/tools/test/cover_SUITE_data
AgeCommit message (Collapse)Author
2013-01-25Fix a bug in cover when used with no_auto_importJosé Valim
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.
2013-01-25cover now relies on the compile info to find file sourcesJosé Valim
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).
2012-10-30[cover] Allow reconnection if node has been disconnected or downSiri Hansen
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).
2011-11-07beam_asm: Strenghten the calculation of Uniq for funsBjörn Gustavsson
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.)
2010-01-19Add test suite for the tools applicationBjörn Gustavsson