Can't use an undefined value as an ARRAY reference at ./ line 3387. when running checksetup script




Installation & Upgrading
15 years ago
5 years ago


(Reporter: Keith Kemp, Assigned: zach)




(1 attachment)

712 bytes, patch
Max Kanat-Alexander
: review-
Details | Diff | Splinter Review


15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Build Identifier: 

Switched bugzilla to a new server and now get this error.  This error was not 
present on the previous server.  

Reproducible: Always

Steps to Reproduce:


15 years ago
OS: other → FreeBSD
Version: unspecified → 2.17.4

Comment 1

15 years ago
There was no upgrade.  It was from 2.17.4 to 2.17.4  The database was dumped 
and then added to the new server.
Mysql server version: 4.0.15-log

Comment 2

15 years ago
I can't reproduce this. Did this happen after you'd already tried and failed to 
run checksetup once? (I remember something about a wrong DBD version on irc). 
Can you still repro it on a fresh export/import/checksetup?

Comment 3

15 years ago
After upgrading to 2.17.5 error is now:
[Mon Nov  3 03:15:54 2003] Can't use an undefined value as an 
ARRAY reference at ./ line 3505.

I can't find the original backup file I used anymore so I'm not able to test 
that.  Is there anything I can do to fix up my database so that this error 
will not happen?
Version: 2.17.4 → 2.17.5

Comment 4

15 years ago

The current mysql backup.

Comment 5

15 years ago
3502    $sth = $dbh->prepare("SELECT fieldid FROM fielddefs " . 
3503                         "WHERE name=''");
3504    $sth->execute();
3505    my $old_field_id = $sth->fetchrow_arrayref()->[0] || 0;

The problem, I believe, is that the query doesn't return any rows, so $sth-
>fetchrow_arrayref() returns undef. If you do the select query above in mysql, 
what are the results it returns?

Copying myk, I'm not familiar enough with the code in question to recommend a 
fix to your DB or to the code. I'll try to dig deeper. That section of code 
converts the old attachment statuses to flags.

Comment 6

15 years ago
Yeah, that's not returning any rows

mysql> SELECT fieldid FROM fielddefs WHERE name='';
Empty set (0.00 sec)

Comment 7

15 years ago
The below is qualified by the fact that all I've been doing is reading code, 
not testing.

It looks as though the first time you attempted to run checksetup, it managed 
to get through to line 3618: 
$dbh->do("DELETE FROM fielddefs WHERE name=''");

but it didn't run the drop table attachstatuses and drop table attachstatusdefs 
twenty lines above that. Do you still have the error on hand from when you 
attempted to run it with a version of DBD::mysql (I think) that was wonky? I'd 
like to know what line it crapped out on.

You might try to drop the two tables (attachstatuses, attachstatusdefs) 
manually from the DB, and then run checksetup, and see what all happens. This 
will serve to avoid the problem block of code, but won't update attach statuses 
into flags if that has not already happened.

You could also instead try changing the line:

my $old_field_id = $sth->fetchrow_arrayref()->[0] || 0;


my $old_field_id = $sth->fetchrow_array() || 0;

and see if that changes anything. That will stop the erroring. I -think- undef 
|| 0 will put 0 into $old_field_id. If it doesn't, break it into two lines:

my $old_field_id = $sth->fetchrow_array();
$old_field_id = 0 unless defined $old_field_id;

I'll follow my own suggestions with the backup you provided when I get home.

Comment 8

15 years ago
Created attachment 134731 [details] [diff] [review]
avoid error

OK. I can verify that your DB does indeed cause this error. The attached patch
gets rid of the error and allows checksetup to run. It still whines with the
following warnings:

[Mon Nov  3 19:45:50 2003] DBD::mysql::st execute failed:
Unknown column 'product_id' in 'field list' at ./ line 3528.
[Mon Nov  3 19:45:50 2003] DBD::mysql::st fetchrow_array failed:

fetch() without execute() at ./ line 3529.

In this case these errors are meaningless, because what was posted had no
entries in the attachstatuses or attachstatusdefs table.

A quick look around seemed to be that things were ok. Sanitycheck complained
about this and that, but I don't know whether they were from before or after
the transfer. Should be before, things like having open bugs with a resolution.

Apply the patch, if you would, and try it out.


15 years ago
Severity: normal → major
Ever confirmed: true
OS: FreeBSD → All


13 years ago
Attachment #134731 - Flags: review?(mkanat)

Comment 9

13 years ago
Comment on attachment 134731 [details] [diff] [review]
avoid error

Yeah, we can't get into automatically fixing failures of checksetup.

I don't want checksetup to just go along silently if something is messed up --
I want it to fail. So the error message that exists is correct. :-)

The real problem would have been whatever caused his checksetup to fail in the
first place, which is hopefully handled by now.
Attachment #134731 - Flags: review?(mkanat) → review-

Comment 10

13 years ago
We don't automatically fix past failures of checksetup, unless they were
well-known failures in an official release. That's just an impossible can of
worms to get in to.
Last Resolved: 13 years ago
Hardware: PC → All
Resolution: --- → WONTFIX
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.