Tracking down an uninitialized value warning

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

Yesterday I looked in one of my apache error logs, and noticed that one of my CGI apps was spitting out lots of 'uninitialized value' warnings. This happens from time to time, and is no big deal. But they bug me, so any time I notice them I take a look at the code and tidy up whatever it was that was causing them.

However, this time I'm completely stumped.

Firstly, here is the offending code (for clarity, I removed some bits which are not relevant):

for my $test (@testlist) {
    if (defined $tref->{$host}{$test}) {
        my $status = $tref->{$host}{$test}{status};
        my $duration = $tref->{$host}{$test}{dur};
        # debugging line
        if (!$tref->{$host}{$test}{status}) { print "$host=>$test\n";}

        # Some more processing here which is not relevent
    }
    else {
        print "\t<th>-</th>\n";
   }
}
[download]

The above code is part of a bigger loop, that is iterating through a list of around 500 'hosts'. For each of these 'hosts', it will iterate through a list of 'tests', and for each one it checks to see if we have data for that test/host combination. If data is present, it gets used. Otherwise just a dash '-' is ouput (the else part of the loop).

What I found was that just one single host/test combination (out of several thousand) was throwing the warning. With the print debugging line added, I narrowed it down to the 'http' test on the 'vnsgnnwwor-gw-1' host.

However - and this is the part that has me completely stumped - when I did a print Dumper($tref);¹ immediately before this loop, the output for this particular host was:

 'vnsgnnwwor-gw-1' => {
                         'conn' => {
                                     'dur' => '2.09 hours',
                                     'status' => 'red'
                                   },
                         'mrtg' => {
                                     'dur' => '4.00 hours',
                                     'status' => 'green'
                                   }
                       },
[download]

So I've confirmed that the 'http' data for this host does not exist. So therefore my question is - how on earth is this getting past the conditional in the 'if' statement at the top of the loop? Am I being bitten by autovivification? If I am, then my understanding of how autovivification works is obviously way off. And if is is autovivification, then it doesn't make sense. Because there would be dozens and dozens of other test/host combinations that would also slip through - but only this single one is.

I can't help having the feeling that I'm missing something blatantly obvious here. Anyway, somebody please put me out of my misery.

Update: Okay, I have figured this one out, and I was being bitten by autovivification. Here is a self-contained example that demonstrates:

#!/usr/bin/perl -l
use strict;
use warnings;

my $tref = {
    'vnsgnnwwor-gw-1' => {
        'conn' => {
            'dur' => '2.09 hours',
            'status' => 'red'
        },
        'mrtg' => {
            'dur' => '4.00 hours',
            'status' => 'green',
        },
    },
    };

my $host = 'vnsgnnwwor-gw-1';
my $test = 'http';

print "$host is ", defined $tref->{$host} ? "True" : "False";
print "$test is ", defined $tref->{$host}{$test} ? "True" : "False";
print "$test=>status is ", defined $tref->{$host}{$test}{status} ? "Tr
+ue" : "False";
print "$test is ", defined $tref->{$host}{$test} ? "True" : "False";
[download]

And the output of the above is:

vnsgnnwwor-gw-1 is True
http is False
http=>status is False
http is True
[download]

Note that the first time I test for 'http', it returns false. But the second time that I test for it, it returns true. This is because (if my understanding of autovivification is correct), when I test for $tref->{$host}{$test}{status} - Perl obligingly creates the $test part of that datastructure for me - thanks to autovivification.

I feel much better now :)

Thanks,
Darren :)

1. I use Data::Dumper::Simple for debugging

Comment on Tracking down an uninitialized value warning Select or Download Code

Replies are listed 'Best First'.
Re: Tracking down an uninitialized value warning by quester (Vicar) on Jun 14, 2007 at 07:06 UTC
As has been observed many times, constants aren't, variables won't.... I'm suspicious of the "# Some more processing here which is not relevant" section after the more obvious suspects have been eliminated. Have you tried moving the "print Dumper($tref)'" inside your debugging if statement, to see if something in the loop might be sneaking extra entries into %{$tref}? You might also try printing the values of all the variables in the loop and the values of exists $tref->{$host}{$test}{status} and defined $tref->{$host}{$test}{status} inside that debugging if statement. Murphy's law of debugging with print statements: the one value that is so redundant and predictable that you can eliminate any need to print it in your sleep is the one that contains the erroneous value. Unless you expected that to happen, in which case it won't.	[reply]
Re^2: Tracking down an uninitialized value warning by McDarren (Abbot) on Jun 14, 2007 at 08:24 UTC
I'm suspicious of the "# Some more processing here which is not relevant" section.. Ok, well for the record - here are the lines that I removed: `my $icon = "$themepath/$status.gif"; my $testdetails = "/bb/html/$host.$test.html"; print qq(\t<th><a href="$testdetails">), qq(<img src="$icon" border="0" alt="$status" $iconsize title="$test +: $status since $duration ago">), qq(</a></th>\n);` [download] Basically, I was getting a warning anytime I tried to use `$status`, obviously because it was undefined. Anyway, since posting earlier I've been out for lunch and cleared my head a bit and just taken another look at it. And I've found that if I change the conditional in the if statement to: `if (defined $tref->{$host}{$test}{status}) {` [download] ...the warnings disappear. Although this has solved my immediate problem, I'm still puzzled as to why.. `defined $tref->{$host}{$test}` [download] ..returns true in this case, yet `defined $tref->{$host}{$test}{status}` [download] ..returns false - when I know for a fact (from the dumper output) that `$tref->{$host}{$test}` does not exist. Thanks for your feedback :)	[reply] [d/l] [select]
Re: Tracking down an uninitialized value warning by sen (Hermit) on Jun 14, 2007 at 07:09 UTC
Hi, Change the condition. It may works, please check `if (exists $tref->{$host}{$test})` [download]	[reply] [d/l]
Re: Tracking down an uninitialized value warning by GrandFather (Saint) on Jun 14, 2007 at 08:13 UTC
Which line generates the error and how do you know which variable on that line is the culprit? I'm sure you know that the line number can be misleading due to if statements and such. Can you reproduce the problem in a smaller sample program? Is it consistent? (That is, it always faults for the same input data.) Does it fault if you comment out the "irrelevant" stuff? DWIM is Perl's answer to Gödel	[reply]
Re^2: Tracking down an uninitialized value warning by McDarren (Abbot) on Jun 14, 2007 at 08:31 UTC
GrandFather, Have a look at my reply to quester. Basically the crux of my question boils down to the final paragraph in that reply.	[reply]