787123 - DB/Schema.pm: bug on line 1815, use of uninitialized value in exists

Status: RESOLVED WORKSFORME

(Bugzilla :: Whining, defect)

Description

[Greg Hansen]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)

Steps to reproduce:

Observer the error messages being output by Bugzilla:

Use of uninitialized value in exists at Bugzilla/DB/Schema.pm line 1815.


Actual results:

The code is trying to check for the existence of an entry in an array with the key DEFAULT, but as written it checks to see if the array value with that key has ever been defined. 

The code:

            if (exists($field_def->{DEFAULT})
                && exists($db_specific->{$field_def->{DEFAULT}})) {
                $field_def->{DEFAULT} = $db_specific->{$field_def->{DEFAULT}};
            }
 
When this is executed for some fields, the DEFAULT key does not exist, so $field_def{DEFAULT} is uninitialized.


Expected results:

The code should be testing the keys to see if DEFAULT is one of them, not testing for the existence of the value $field_def{DEFAULT}. This might be accomplished with:

sub {
   my (@testArray,$targetKey) = @_;
   for $thisValue (keys @testArray) {
        if ($thisValue eq $targetKey) {return True}
   }
   return False; 
}

I have not tested the above, but it gives you the idea.

Comment 1

[Greg Hansen]

I forgot to name the subroutine; call it "hasKey", then line 1815 becomes

     if (hasKey($field_def,DEFAULT))

same for the test on line 1816.

Comment 2

[Frédéric Buclin]

How did you manage to get this error, and with which version of Bugzilla exactly? We need steps to reproduce. Either DEFAULT doesn't exist, or it exists and is defined. If there is a DEFAULT => undef somewhere, this sounds like a bug to me.

Comment 3

[Greg Hansen]

The error appears in the output from whine.pl, a cron job that seems to give us the output that needs attention from the bugzilla logs. We are running 3.6. I am not sure what event is happening when it emits the error message.

The bug is subtle. If you read the documentation for the "exists" function, it is testing to see if the indicated array value has ever been set, even if it is currently undefined. But since the value DEFAULT that is used as the index does not exist in the array (see lines 219 versus 220:

         value    => {TYPE => 'varchar(64)', NOTNULL => 1},
         sortkey  => {TYPE => 'INT2', NOTNULL => 1, DEFAULT => 0},

where the field "value" does not have a DEFAULT entry, but the field "sortkey" does. What the code SHOULD be asking, as I've noted above, is whether the key DEFAULT exists in the hash, not whether the value for DEFAULT has ever been set.


The consequence of this error is that Perl natters at you. Since it is only fields that do not have DEFAULT keys that generate this, the fact that you don't set the DEFAULT in the adjusted array doesn't matter.

It would be nice not to get these error messages all the time, though. We get six lines per day.

Comment 4

[Greg Hansen]

If you tell me where the logs are kept, I can try to get more info.

Comment 5

[Frédéric Buclin]

The code you are reporting is not at line 1815 but at line 1706 in Bugzilla 3.6. So it looks like you edited the code in some way or another. Moreover, Bugzilla 3.6 is a very old release (the current version on this branch is 3.6.11) and is restricted to security fixes only.

The code is correct and looks at each field individually to get the DEFAULT value if defined.