[MDEV-33381] armhf: MTR failures in Spider and versioning tests Created: 2024-02-05  Updated: 2024-02-05

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Otto Kekäläinen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDBF-155 Test running (almost) all tests on al... Closed
relates to MDEV-32188 make TIMESTAMP use whole 32-bit unsig... In Testing

 Description   

Note: armhf is not an officially supported platform by MariaDB. This bug report is filed mainly for tracking purposes and is unlikely to be fixed unless some new Raspberry PI / armhf enthusiast steps up and contributes fixes, or at least contributes debugging to make the issues obvious and easy to fix.


When running the full MariaDB 10.11 test suite (--big-test) on armhf on the following tests have failures (when run on Launchpad builders):

    federated.federatedx_versioning
    federated.federatedx_versioning
    spider/bg.basic_sql
    spider/bg.basic_sql
    spider/bg.spider_fixes spider/bg.spider_fixes_part spider/bg.spider3_fixes spider/bg.spider3_fixes_part
    spider/bg.spider_fixes_part
    spider.auto_increment spider.basic_sql
    spider.basic_sql_part spider.basic_sql
    spider.spider3_fixes_part spider.spider3_fixes spider.spider_fixes_part spider.spider_fixes
    spider.spider_fixes_part
    versioning.trx_id
    versioning.trx_id
    versioning.online
    versioning.online
    versioning.partition
    versioning.partition
    period.versioning

This happens on Ubuntu 22.04 (Jammy), 23.10 and 24.04:

Summaries of failures from log:

federated.federatedx_versioning 'X,innodb,trx_id' w1 [ fail ]
        Test ended at 2024-02-05 01:01:30
 
CURRENT_TEST: federated.federatedx_versioning
mysqltest: At line 18: query 'insert into t1 values (1)' failed: <Unknown> (2013): Lost connection to server during query
..
Query (0xf0a0e010): insert into t1 values (1)

spider/bg.basic_sql                      w3 [ fail ]
        Test ended at 2024-02-05 01:16:35
 
CURRENT_TEST: spider/bg.basic_sql
mysqltest: At line 1875: query 'UPDATE ta_l a, tb_l b SET a.b = b.b, a.c = b.c WHERE a.a = b.a' failed: <Unknown> (2026): TLS/SSL error: unexpected eof while reading
 
The result from queries just before the failure was:
< snip >
tb_l);
connection master_1;
SELECT a, b, date_format(c, '%Y-%m-%d %H:%i:%s') FROM ta_l ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
1	g	2009-03-03 03:03:03
2	g	2009-03-03 03:03:03
 
update select a
connection master_1;
UPDATE ta_l SET b = 'h', c = '2010-04-04 04:04:04' WHERE a = (SELECT a FROM
tb_l ORDER BY a LIMIT 1);
connection master_1;
SELECT a, b, date_format(c, '%Y-%m-%d %H:%i:%s') FROM ta_l ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
1	h	2010-04-04 04:04:04
2	g	2009-03-03 03:03:03
 
update join
connection master_1;
UPDATE ta_l a, tb_l b SET a.b = b.b, a.c = b.c WHERE a.a = b.a;

spider/bg.spider_fixes_part              w2 [ fail ]
        Test ended at 2024-02-05 01:16:39
 
CURRENT_TEST: spider/bg.spider_fixes_part
mysqltest: At line 272: query 'UPDATE ta_l2 SET a = 4 WHERE a = 3' failed: <Unknown> (2026): TLS/SSL error: unexpected eof while reading
 
The result from queries just before the failure was:
< snip >
ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
2	b	2000-01-01 00:00:00
3	e	2007-06-04 20:03:11
4	d	2003-11-30 05:01:03
5	c	2001-12-31 23:59:59
 
2.23
partition update with moving partition
connection master_1;
DROP TABLE IF EXISTS ta_l2;
connection master_1;
CREATE TABLE ta_l2 (
a INT,
b CHAR(1),
c DATETIME,
PRIMARY KEY(a)
) MASTER_1_ENGINE MASTER_1_COMMENT2_P_2_1
INSERT INTO ta_l2 (a, b, c) VALUES (3, 'B', '2010-09-26 00:00:00');
UPDATE ta_l2 SET a = 4 WHERE a = 3;

spider.basic_sql                         w2 [ fail ]
        Test ended at 2024-02-05 01:17:23
 
CURRENT_TEST: spider.basic_sql
mysqltest: At line 1875: query 'UPDATE ta_l a, tb_l b SET a.b = b.b, a.c = b.c WHERE a.a = b.a' failed: <Unknown> (2026): TLS/SSL error: unexpected eof while reading
 
The result from queries just before the failure was:
< snip >
tb_l);
connection master_1;
SELECT a, b, date_format(c, '%Y-%m-%d %H:%i:%s') FROM ta_l ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
1	g	2009-03-03 03:03:03
2	g	2009-03-03 03:03:03
 
update select a
connection master_1;
UPDATE ta_l SET b = 'h', c = '2010-04-04 04:04:04' WHERE a = (SELECT a FROM
tb_l ORDER BY a LIMIT 1);
connection master_1;
SELECT a, b, date_format(c, '%Y-%m-%d %H:%i:%s') FROM ta_l ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
1	h	2010-04-04 04:04:04
2	g	2009-03-03 03:03:03
 
update join
connection master_1;
UPDATE ta_l a, tb_l b SET a.b = b.b, a.c = b.c WHERE a.a = b.a;

spider.spider_fixes_part                 w1 [ fail ]
        Test ended at 2024-02-05 01:17:28
 
CURRENT_TEST: spider.spider_fixes_part
mysqltest: At line 272: query 'UPDATE ta_l2 SET a = 4 WHERE a = 3' failed: <Unknown> (2026): TLS/SSL error: unexpected eof while reading
 
The result from queries just before the failure was:
< snip >
ORDER BY a;
a	b	date_format(c, '%Y-%m-%d %H:%i:%s')
2	b	2000-01-01 00:00:00
3	e	2007-06-04 20:03:11
4	d	2003-11-30 05:01:03
5	c	2001-12-31 23:59:59
 
2.23
partition update with moving partition
connection master_1;
DROP TABLE IF EXISTS ta_l2;
connection master_1;
CREATE TABLE ta_l2 (
a INT,
b CHAR(1),
c DATETIME,
PRIMARY KEY(a)
) MASTER_1_ENGINE MASTER_1_COMMENT2_P_2_1
INSERT INTO ta_l2 (a, b, c) VALUES (3, 'B', '2010-09-26 00:00:00');
UPDATE ta_l2 SET a = 4 WHERE a = 3;

versioning.trx_id 'innodb'               w2 [ fail ]
        Test ended at 2024-02-05 01:19:05
 
CURRENT_TEST: versioning.trx_id
mysqltest: At line 29: query 'commit' failed: <Unknown> (2013): Lost connection to server during query
 
The result from queries just before the failure was:
set default_storage_engine= innodb;
create or replace table t1 (
x int,
sys_trx_start bigint(20) unsigned as row start invisible,
sys_trx_end bigint(20) unsigned as row end invisible,
period for system_time (sys_trx_start, sys_trx_end)
) with system versioning;
# No history inside the transaction
start transaction;
insert into t1 (x) values (1);
update t1 set x= x + 1;
update t1 set x= x + 1;
commit;

versioning.online 'innodb,release,trx_id' w4 [ fail ]
        Test ended at 2024-02-05 01:19:55
 
CURRENT_TEST: versioning.online
mysqltest: At line 26: query 'insert into t values (1, 0)' failed: <Unknown> (2013): Lost connection to server during query
 
The result from queries just before the failure was:
< snip >
alter table t add system versioning, lock=none;
ERROR 0A000: LOCK=NONE is not supported. Reason: Not implemented for system-versioned timestamp tables. Try LOCK=SHARED
alter table t add system versioning, algorithm=inplace;
ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Not implemented for system-versioned timestamp tables. Try ALGORITHM=COPY
alter table t add system versioning, lock=shared;
alter table t add column b int, change column a a int without system versioning, lock=none;
alter table t drop system versioning, lock=none;
ERROR 0A000: LOCK=NONE is not supported. Reason: Not implemented for system-versioned operations. Try LOCK=SHARED
alter table t drop system versioning, algorithm=inplace;
create or replace table t (
a int, b int,
row_start SYS_DATATYPE as row start invisible,
row_end SYS_DATATYPE as row end invisible,
period for system_time (row_start, row_end)
) with system versioning;
insert into t values (1, 0);

versioning.partition 'innodb,trx_id'     w4 [ fail ]
        Test ended at 2024-02-05 01:20:00
 
CURRENT_TEST: versioning.partition
mysqltest: At line 28: query 'insert into t1 values (3), (300)' failed: <Unknown> (2013): Lost connection to server during query
 
The result from queries just before the failure was:
set @save_persistent=@@global.innodb_stats_persistent;
set global innodb_stats_persistent= 0;
call mtr.add_suppression("need more HISTORY partitions");
set system_versioning_alter_history=keep;
# Check conventional partitioning on temporal tables
create or replace table t1 (
x int,
row_start SYS_DATATYPE as row start invisible,
row_end SYS_DATATYPE as row end invisible,
period for system_time(row_start, row_end))
with system versioning
partition by range columns (x) (
partition p0 values less than (100),
partition p1 values less than (1000));
insert into t1 values (3), (300);

period.versioning 'innodb,trx_id'        w1 [ fail ]
        Test ended at 2024-02-05 01:20:12
 
CURRENT_TEST: period.versioning
mysqltest: At line 12: query 'insert into t values('1999-01-01', '2018-12-12'),
('1999-01-01', '1999-12-12')' failed: <Unknown> (2013): Lost connection to server during query
 
The result from queries just before the failure was:
# DELETE
create table t (
s date, e date,
row_start SYS_TYPE as row start invisible,
row_end SYS_TYPE as row end invisible,
period for apptime(s, e),
period for system_time (row_start, row_end)) with system versioning;
insert into t values('1999-01-01', '2018-12-12'),
('1999-01-01', '1999-12-12');

versioning.autoinc 'innodb,trx_id'       w1 [ fail ]
        Test ended at 2024-02-05 01:20:12
 
CURRENT_TEST: versioning.autoinc
mysqltest: At line 19: query 'insert into t1(x, y) values(1, 11)' failed: <Unknown> (2013): Lost connection to server during query
 
The result from queries just before the failure was:
create table t1(
id int unsigned auto_increment primary key,
x int unsigned,
y int unsigned,
sys_start SYS_DATATYPE as row start invisible,
sys_end SYS_DATATYPE as row end invisible,
period for system_time (sys_start, sys_end))
with system versioning;
create table t2(
id int unsigned auto_increment primary key,
x int unsigned,
y int unsigned);
insert into t1(x, y) values(1, 11);

Many of these seem to be related to time. Perhaps this armhf as 32-bit platform has some year 2038 adaptations which MariaDB isn't compatible - but this is just pure speculation. I will however re-test this once MDEV-32188 is done to see if it made a difference.


Generated at Thu Feb 08 10:38:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.