310108 - checksetup.pl fails if attachstatuses or attachstatusdefs tables are empty

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect, P2)

Description

[imorgan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc3 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc3 Firefox/1.0.6

After upgrading via CVS from 1.17.4 to 1.18.3, checksetup.pl gets as far as
'Converting attachment statuses to flags' then dies with: Can't use an undefined
value as an ARRAY reference at ./checksetup.pl line 3679.


Reproducible: Always

Steps to Reproduce:
1. Upgrade 1.17.4 to 1.18.3 via CVS
2. run checksetup.pl

Actual Results:  
checksetup.pl fails with error 'Can't use an undefined value as an ARRAY
reference at ./checksetup.pl line 3679.'

Expected Results:  
./checksetup.pl should graceully handle the fact that the desired tables exist
but are empty.


Dropped the attachstatuses and attachstatusdefs tables, which were both empty.
Then re-running checksetup.pl completes sucessfully.

Comment 1

[Max Kanat-Alexander]

Ahh, yeah. We've had other reports of this bug, but I had no idea what was
causing it. I'll look into it and see what we can do. The Bugzilla 2.18 branch
will be frozen before I can fix this, but we can probably get the fix into
2.20.1 or so.

Comment 2

[Frédéric Buclin]

Fix it in 2.18.5, being unable to upgrade is as painful as security bugs. ;)

Comment 3

[Frédéric Buclin]

checksetup.pl:

    # Get IDs for the old attachment status and new flag fields.
    $sth = $dbh->prepare("SELECT fieldid FROM fielddefs " . 
                         "WHERE name='attachstatusdefs.name'");
    $sth->execute();
    my $old_field_id = $sth->fetchrow_arrayref()->[0] || 0;

If 'attachstatusdefs.name' is not in the fielddefs table, is fetchrow_arrayref()
undefined or an empty array? From the error message, it looks like it's
undefined and then is not a valid array.

mkanat, under which circumstances could this field not be in the fielddefs table?

Comment 4

[Max Kanat-Alexander]

(In reply to comment #3)
> mkanat, under which circumstances could this field not be in the fielddefs 
> table?

  Hrm... well, the interesting question is: Was it ever in the table? The
AddFDef statements are no longer in checksetup.pl, so they won't get added if
they don't exist. The thing to do is to use bonsai to look at checksetup from
2.17.4, and see what's going on there.

Comment 5

[Nick Barnes]

It was in the fielddefs table from 2.16rc1 to 2.16.10 inclusive.
$ grep -n attachstatusdefs.name */checksetup.pl
bugzilla-2.16.1/checksetup.pl:1748:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.10/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.2/checksetup.pl:1771:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.3/checksetup.pl:1775:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.4/checksetup.pl:1776:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.5/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.6/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.7/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.8/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16.9/checksetup.pl:1783:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16/checksetup.pl:1748:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16rc1/checksetup.pl:1687:AddFDef("attachstatusdefs.name", "Attachment Status", 0);
bugzilla-2.16rc2/checksetup.pl:1731:AddFDef("attachstatusdefs.name", "Attachment Status", 0);

Comment 6

[Nick Barnes]

So this is curious: how could the attachstatusdefs table exist without this row being in fielddefs?  For it to exist at all, I think this database must have been running some 2.16 branch sources at some point.
But we should still be conservative in what we accept.

Comment 7

[Frédéric Buclin]

sounds like a dupe of bug 307662 comment 8. maybe the DB was manually altered?

Comment 8

[imorgan]

(In reply to comment #7)
> sounds like a dupe of bug 307662 comment 8. maybe the DB was manually altered?
> 

No the DB was not manually altered. I do not know how the database ended up in that state.

Comment 9

[Max Kanat-Alexander]

OK, I have confirmed locally that it doesn't require any manual DB alteration to make this bug occur. I'm working on it, now.

Comment 10

[Max Kanat-Alexander]

The problem seems to be this:

* The tables existed before the fields were in fielddefs, apparently.
* If you upgrade from such a version, the tables will exist but the fielddefs 
  won't.

Comment 11

[Max Kanat-Alexander]

Attachment: v1

OK, this fixes the DBI calls to avoid the possibility of that situation. It's a very simple patch. I tested it on a 2.12 upgrade (which was affected by the bug, originally) and a 2.16 upgrade (which was not affected by the bug) and they both work.

Comment 12

[Frédéric Buclin]

Comment on attachment 205326 [details] [diff] [review]
v1

This fix is consistent with my comment 3. r=LpSolit by inspection.

Comment 13

[Frédéric Buclin]

I suppose 2.18 is affected too?

Comment 14

[Dave Miller [:justdave]]

(In reply to comment #13)
> I suppose 2.18 is affected too?

Probably, but we no longer support upgrading to 2.18 (it's on security-only now).  

Anyone upgrading to a 2.18.x version should already have an earlier 2.18.x and trying to avoid invasive changes, and if they've already got 2.18.x, then they will have already run into this and found a way to work around it.  Anyone considering an upgrade from something earlier than 2.18.0 should be upgrading to 2.20.

Comment 15

[Max Kanat-Alexander]

tip:

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.458; previous revision: 1.457
done

2.20:

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.412.2.16; previous revision: 1.412.2.15
done