400041 - checksetup.pl crashes if data/mining/-All- exists but the series DB table doesn't

Status: NEW

(Bugzilla :: Installation & Upgrading, defect)

Description

[Frédéric Buclin]

I wanted to install Bugzilla 3.1.2 in a clean new DB using my existing bugzilla/ installation. As I used it for an older version of Bugzilla (3.1.1), data/mining/-All- was already present, but the new DB was not yet created. So I happily ran checksetup.pl and it crashed with the following error message:

Can't use an undefined value as a HASH reference at Bugzilla/Install/DB.pm line 1985.

This errors is located in _copy_old_charts_into_database() at line:

 my %fielddata = %{$data{$field}};

This error occurs because the whole data/mining/-All- file is seen as a single line, because collectstats.pl, which is the creator of this file, explicitly uses \n:

 print DATA (join '|', @row) . "\n";

and so Windows doesn't break lines on it. As the first line is a comment, checksetup.pl on Windows skips the whole file, meaning that $data{$field} remains undefined, generating the error above.

As this code is supposed to create missing series required by new charts, this means that new charts cannot work. Kind of dataloss.

checksetup.pl on Linux is not affected as the line break is really "\n". Should we use something similar to Doctor::File->linebreak? Either that or force checksetup.pl to see "\n" as a line break even on Windows.

Targetting this bug to 3.0 as I suspect this branch is affected too.

Comment 1

[Max Kanat-Alexander]

Creating a new DB with your existing data/ directory isn't necessarily a supported action of checksetup.pl, so this isn't a blocker.

Comment 2

[Dave Miller [:justdave]]

The way this bug is described I bet this kills upgrades from pre-new-charts on Windows, too, not just installs to new DBs.

Comment 3

[Frédéric Buclin]

Bugzilla/Install/Requirements.pm, line 288: $/ = "\015\012" if ON_WINDOWS;

This may interfere with what $/ should be when reading files in data/mining/. Would |local $/ = "\n"| in _copy_old_charts_into_database() fix it?

Comment 4

[Max Kanat-Alexander]

There were no supported versions of Bugzilla on Windows pre New-Charts.

Comment 5

[Dave Miller [:justdave]]

(In reply to comment #4)
> There were no supported versions of Bugzilla on Windows pre New-Charts.

OK, fair enough.

Comment 6

[Frédéric Buclin]

Still related to this bug:

Argument "" isn't numeric in addition (+) at Bugzilla/Install/DB.pm line 1973.

The culprit is also in _copy_old_charts_into_database():

  $data{$open_name}{$numbers[0]} += $numbers[$i + 1];

Comment 7

[Frédéric Buclin]

The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.

Comment 8

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).

Comment 9

[Frédéric Buclin]

Maybe we should simply rename data/mining to data/mining.old to not crash checksetup.pl. I just hit this bug again.