Skip to content


Structure database doesn't always find its associated file #36

rolfyone opened this Issue · 1 comment

2 participants


Hopefully this is the correct place to submit this issue, apologies in advance if its not!


I'm working on a bunch of old perl code, trying to use Devel::Cover to write to and keep a single 'cover_db' so that I can see overall code coverage of a bunch of semi related scripts. While I've been doing this, I've noticed on several occasions some messages like:

Devel::Cover: Can't open for MD5 digest: No such file or directory

These aren't too bad, but in some instances, they've affected text diff tests which is less than ideal (I know, don't use diffs in tests, long story, not changing, I won't start a rant on that here).

To remove these warnings, I started off by hacking them out, but that's obviously not ideal, as in most instances its a very worth while error to know about.


On my larger code base, these errors are most annoying when they come out about files that aren't related to what's being run. For example, you're running a, and warnings show up about, or modules that aren't used directly or indirectly.
These get shown because when the Structure module reads its cache, it finds a digest to process, but in some circumstances it's got '' and that's not in the working folder, so it reports a warning.
The two solutions that came immediately to mind were:
1> don't bother pre-parsing the Structure database, do lazy loading.
2> Instrument the with enough information to find the file it's attempting to load in the event that 'file' doesn't resolve.

Steps to reproduce:

(linux example - but i'm sure someone in windows could show the same issue in a slightly different way)

rm -rf ${HOME}/cover_db
export PERL5OPT=-MDevel::Cover=-db,${HOME}/cover_db
cat >/tmp/ <<EOF 
#!/usr/bin/env perl
print "Hello World!\n";
chmod +x /tmp/
cd /tmp
perl /tmp/

I use Devel::Cover via PERL5OPT as its the most effective way to be looking at coverage of pre-existing code, and having a single database just makes life easier.

Proposed solution:

I opted for the path of least resistance in my fix: (based on v.0.98 change to

> use Cwd "abs_path";
>     $self->{abs_file} = abs_path($file);
>         $self->{f}{$file}{abs_file} = abs_path($file);
<     my $d        = $self->digest($s->{file});
>     my $d = (-f $s->{file} ? $self->digest($s->{file}) : $self->digest($s->{abs_file})) ;

It seems to be much happier once this is done. Obviously pre-existing digest files will still exhibit the same problem, as they don't have the abs_file attribute, the scenario above will not generate the warning with this change to

There's been several threads online about this kind of issue, and I think there's been some that basically say it's not a problem, but I believe this might lend weight to it being acknowledged and hopefully fixed (either in this way or another like lazy loading which would have the added benefit of performance improvement).

@bmartin bmartin added a commit to bmartin/Devel--Cover that referenced this issue
@bmartin bmartin Store absolute path to files in Structure files
If you run "cover" to create the coverage report in a different directory from where you ran your tests, the coverage report is not able to find the scripts. For large codebases with many scattered tests, it is not feasible to always run the tests from one location. For example, I need coverage data for a script that needs to be run in several different directories.

This change is based on @rolfyone's proposed change in this issue:

Hi @rolfyone,

I just merged your suggested changes into the current tip and created a commit:


It does not quite solve the problem since the html generated does not have the right files. At least the summary information is correct. I'm still trying to figure out how to make the rest of the code understand the 'abs_file' field that is now written into the structure files.

Figured I'd share my progress so far in case anybody else is trying this.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.