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

NEW
Unassigned

Status

()

11 years ago
5 years ago

People

(Reporter: LpSolit, Unassigned)

Tracking

Bug Flags:
blocking3.1.3 -
blocking3.0.3 -

Details

(Reporter)

Description

11 years ago
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.
Flags: blocking3.1.3?
Flags: blocking3.0.3?
Creating a new DB with your existing data/ directory isn't necessarily a supported action of checksetup.pl, so this isn't a blocker.
Severity: normal → minor
Flags: blocking3.1.3?
Flags: blocking3.1.3-
Flags: blocking3.0.3?
Flags: blocking3.0.3-
The way this bug is described I bet this kills upgrades from pre-new-charts on Windows, too, not just installs to new DBs.
Severity: minor → major
Flags: blocking3.1.3?
Flags: blocking3.1.3-
Flags: blocking3.0.3?
Flags: blocking3.0.3-
(Reporter)

Comment 3

11 years ago
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?
There were no supported versions of Bugzilla on Windows pre New-Charts.
Flags: blocking3.1.3?
Flags: blocking3.1.3-
Flags: blocking3.0.3?
Flags: blocking3.0.3-
(In reply to comment #4)
> There were no supported versions of Bugzilla on Windows pre New-Charts.

OK, fair enough.
(Reporter)

Comment 6

11 years ago
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];
(Reporter)

Comment 7

10 years ago
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.
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
(Reporter)

Comment 8

9 years ago
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).
Target Milestone: Bugzilla 3.2 → ---
(Reporter)

Comment 9

8 years ago
Maybe we should simply rename data/mining to data/mining.old to not crash checksetup.pl. I just hit this bug again.
Severity: major → normal
OS: Windows 2000 → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.