Hi, Otto, On May 25, Otto Kekäläinen wrote:
Hi!
I noticed that the autopkgtests on Debian on armhf and armel that run the mariadb-test-run fail on error:
starting mysql-test-tun.pl... Logging: ./mysql-test-run.pl --force --testcase-timeout=120 --suite-timeout=540 --retry=3 -- ... Collecting tests... Installing system database... Can't use an undefined value as an ARRAY reference at lib/My/SysInfo.pm line 166.
Logs for full context: https://ci.debian.net/data/autopkgtest/unstable/armel/m/mariadb/33870767/log... https://ci.debian.net/data/autopkgtest/unstable/armhf/m/mariadb/33870768/log...
This line 166 in mysql-test/lib/My/SysInfo.pm has:
# Return the number of cpus found sub num_cpus { my ($self)= @_; return int(@{$self->{cpus}}) or confess "INTERNAL ERROR: No cpus in list"; }
Can somebody with strong Perl skills help me understand 1) Where this cpus array is inherited from?
cpus is initialized to be an empty list on the line 119: 118 my $self= bless { 119 cpus => (), 120 }, $class; Then it tries to fill it from /proc/cpuinfo (line 67) and `kstat` (line 95). If nothing worked it'll create one dummy cpu: 145 push(@{$self->{cpus}}, 146 { 147 bogomips => DEFAULT_BOGO_MIPS, 148 model_name => "unknown", 149 }); At no point it sets $self->{cpus} to undef, so I don't understand how that error of yours is even possible.
2) Why might it have now regressed in MariaDB 10.11.3 and why is this erroring only on armel/armhf but not other architectures?
It doesn't, this file wasn't touched for ages. Could it be an incredibly ancient perl there? Just a shot in the dark, I don't think it'll explain much. Some distro patches, perhaps?
3) What should I do wrap this section in so that if cpus is not set, it would just default to '1'?
you shouldn't, it already defaults to 1 "unknown" cpu with 2000 bogomips. if you'll simply hack num_cpus() to return 1, it'll fail later on something like $self->{cpus}[0]->{bogomips} Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org