Devel::Cover and symbolic links -- borked?

DrWhy has asked for the wisdom of the Perl Monks concerning the following question:

We have a large application framework here at work that I work on. It's made up of mostly perl scripts and modules (with a mixure of code in other languages, but that's not important now). We have an extensive set of test scripts and want to measure the Perl code coverage. One consequence of the architecture we implemented is that many of the perl scripts are symlinked in multiple locations (each application within the framework has its own code space and code that needs to be shared among different apps is placed in one application's space and symlinked into all the other apps' spaces).

I get what looks like accurate coverage measures out of runs of the full test set for those scripts that are *not* symlinks. For the scripts that are symlinked a few of them seem to give some reasonable coverage data, but most of them show no coverage data at all. They are listed in the HTML report pages, but all usage stats columns, stmt, bran, cond, sub, and time (not doing pod coverage), all say 'n/a'. Some of these scripts are quite large and are surely used many times within the test set but it is essentially reporting 0% coverage which is just not possible.

So it looks like the system is getting confused when you run the same script via different paths (via symlinking).

Is this a known issue and is there any kind of workaround?

In the interest of full disclosure (as much as my company will allow anyway) I did modify Devel::Cover so that it can operate in a parallel grid computing system.

Update: typos fixed.

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

Comment on Devel::Cover and symbolic links -- borked?

Replies are listed 'Best First'.
Re: Devel::Cover and symbolic links -- borked? by pjcj (Novice) on Jul 25, 2011 at 13:41 UTC
My best guess at what is happening is that the coverage for the symlinks is getting merged into one report (this is a feature), but that the symlinks are still getting reported on (this would be a bug). Could that be what is happening here? Are you able to put together a test case? If so, please send it to RT (I don't really follow perlmonks) and I'll have a look at it. If not, just a bug report there would be better than nothing. For future reference, the best place to report stuff like this is probably the perl-qa mailing list. Not that I have any problem with people discussing Devel::Cover wherever they want to - quite the opposite in fact - but when we get to bugs perl-qa or RT is probably needed. I don't suppose there's any chance of getting your parallel modifications into the main distribution?	[reply]
Re^2: Devel::Cover and symbolic links -- borked? by DrWhy (Chaplain) on Jul 25, 2011 at 16:10 UTC
Well, that was easier than I thought. I wasn't even half-way through setting up the test case when the error popped up. It's not at the level of merging multiple runs as I expected, but in measuring the coverage of runs on the symlinks themselves. Here's your test case.: File1 Name: main.pl Content: print "hi\n" File2 Name linkdir/main.pl Content: symlink to File1 Run: $ perl -MDevel::Cover main.pl Devel::Cover 0.76: Collecting coverage data for branch, condition, sta +tement, subroutine and time. Pod coverage is unavailable. Please install Pod::Coverage from CP +AN. Selecting packages matching: Ignoring packages matching: /Devel/Cover[./] Ignoring packages in: . /usr/lib/perl5/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi hi Devel::Cover: Writing coverage database to /path/to/cover_db/runs/1311 +608639.28154 ----------------------------------- ------ ------ ------ ------ ------ + ------ File stmt bran cond sub time + total ----------------------------------- ------ ------ ------ ------ ------ + ------ main.pl 100.0 n/a n/a n/a n/a + 100.0 Total 100.0 0.0 0.0 0.0 n/a + 100.0 ----------------------------------- ------ ------ ------ ------ ------ + ------ $ perl -MDevel::Cover linkdir/main.pl Devel::Cover 0.76: Collecting coverage data for branch, condition, sta +tement, subroutine and time. Pod coverage is unavailable. Please install Pod::Coverage from CP +AN. Selecting packages matching: Ignoring packages matching: /Devel/Cover[./] Ignoring packages in: . /usr/lib/perl5/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi hi Devel::Cover: Writing coverage database to /path/to/cover_db/runs/1311 +608812.28180 ----------------------------------- ------ ------ ------ ------ ------ + ------ File stmt bran cond sub time + total ----------------------------------- ------ ------ ------ ------ ------ + ------ linkdir/main.pl n/a n/a n/a n/a n/a + n/a Total 0.0 0.0 0.0 0.0 n/a + 0.0 ----------------------------------- ------ ------ ------ ------ ------ + ------ [download] The problem is measuring code coverage at all when running a symbolically linked script that is not in the current working director. I didn't show the results, but if you run the same symlinked script without running the 'main' non-linked path first, then it captures the coverage. When you run main.pl first, then run linkdir/main.pl next that's when you get the failure. update: Forgot to mention that you don't get this error when the symlink is in the same directory as what it links to. --DrWhy "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."	[reply] [d/l]
Re^2: Devel::Cover and symbolic links -- borked? by DrWhy (Chaplain) on Jul 25, 2011 at 15:48 UTC
I thought of that, but that is not the case. There is only one listing for each of the the symlinked scripts in the report and it's the one with n/a's all the way across. The behavior you suggested is the one that I hoped for and expected, all the usage for each script, no matter by which path, merged into one report line (preferrably in the name of the main, non-symlink path). Alas, such was not the case. I'll see about putting together a test case. --DrWhy "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."	[reply]