[MDEV-34590] SIGSEGV in spider_db_unlock_tables and ASAN: heap-use-after-free in ha_spider::lock_tables on INSERT - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: 10.6, 10.11, 11.1(EOL), 11.2(EOL), 11.4, 11.5(EOL), 11.6(EOL)
Fix Version/s: N/A
Component/s: Data Manipulation - Insert, Locking, Storage Engine - Spider
Labels:

Description

INSTALL PLUGIN Spider SONAME 'ha_spider.so';

CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET '../socket.sock',DATABASE'',USER'',PASSWORD'');

CREATE TABLE t1 (c1 INT) ENGINE=InnoDB;

CREATE TABLE t2 (c1 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"';

CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider;

SELECT * FROM t2;

SELECT * FROM t3;

LOCK TABLES t2 WRITE;

ALTER TABLE t2 CHANGE c1 c1 DOUBLE;

INSERT INTO t3 VALUES (1);

Leads to:

11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063 (Debug)
Core was generated by `/test/MD190624-mariadb-11.2.5-linux-x86_64-dbg/bin/mariadbd --no-defaults --max'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000014b3100840c6 in spider_db_unlock_tables (spider=spider@entry=0x14b2e41dcd10, link_idx=link_idx@entry=0)at /test/11.2_dbg/storage/spider/spd_db_conn.cc:1282
[Current thread is 1 (LWP 4093349)]
(gdb) bt
#0 0x000014b3100840c6 in spider_db_unlock_tables (spider=spider@entry=0x14b2e41dcd10, link_idx=link_idx@entry=0)at /test/11.2_dbg/storage/spider/spd_db_conn.cc:1282
#1 0x000014b3100eca19 in ha_spider::lock_tables (this=this@entry=0x14b2e41dcd10)at /test/11.2_dbg/storage/spider/ha_spider.cc:11983
#2 0x000014b3100eccd9 in ha_spider::external_lock (this=0x14b2e41dcd10, thd=<optimized out>, lock_type=2)at /test/11.2_dbg/storage/spider/ha_spider.cc:919
#3 0x000056224a4bf899 in handler::ha_external_lock (this=0x14b2e41dcd10, thd=thd@entry=0x14b2e4000d58, lock_type=lock_type@entry=2)at /test/11.2_dbg/sql/handler.cc:7427
#4 0x000056224a620d0e in handler::ha_external_unlock (thd=0x14b2e4000d58, this=<optimized out>) at /test/11.2_dbg/sql/handler.h:3527
#5 unlock_external (thd=thd@entry=0x14b2e4000d58, table=0x14b2e4014e50, count=<optimized out>) at /test/11.2_dbg/sql/lock.cc:744
#6 0x000056224a620efe in mysql_unlock_tables (thd=0x14b2e4000d58, sql_lock=0x14b2e4014e20, free_lock=<optimized out>)at /test/11.2_dbg/sql/lock.cc:435
#7 0x000056224a621513 in mysql_unlock_tables (thd=thd@entry=0x14b2e4000d58, sql_lock=<optimized out>) at /test/11.2_dbg/sql/lock.cc:418
#8 0x000056224a11d37d in close_thread_tables (thd=thd@entry=0x14b2e4000d58)at /test/11.2_dbg/sql/sql_base.cc:976
#9 0x000056224a11d60a in close_thread_tables_for_query (thd=thd@entry=0x14b2e4000d58) at /test/11.2_dbg/sql/sql_base.cc:797
#10 0x000056224a1a8e37 in mysql_execute_command (thd=thd@entry=0x14b2e4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/11.2_dbg/sql/sql_parse.cc:5966
#11 0x000056224a1aa010 in mysql_parse (thd=thd@entry=0x14b2e4000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14b32409e2e0)at /test/11.2_dbg/sql/sql_parse.cc:7920
#12 0x000056224a1ac3d3 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14b2e4000d58, packet=packet@entry=0x14b2e400b2f9 "INSERT INTO t3 VALUES (1)", packet_length=packet_length@entry=25, blocking=blocking@entry=true)at /test/11.2_dbg/sql/sql_class.h:247
#13 0x000056224a1ae76c in do_command (thd=0x14b2e4000d58, blocking=blocking@entry=true) at /test/11.2_dbg/sql/sql_parse.cc:1407
#14 0x000056224a315c49 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x56224d51d908, put_in_cache=put_in_cache@entry=true)at /test/11.2_dbg/sql/sql_connect.cc:1439
#15 0x000056224a315f3e in handle_one_connection (arg=arg@entry=0x56224d51d908)at /test/11.2_dbg/sql/sql_connect.cc:1341
#16 0x000056224a76852c in pfs_spawn_thread (arg=0x56224d4805e8)at /test/11.2_dbg/storage/perfschema/pfs.cc:2201
#17 0x000014b327a97ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444
#18 0x000014b327b2847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

10.5.26 3c508d4c71c8bf27c6ecceba53ab9d4325a1bd6c (Debug, UBASAN)
==205432==ERROR: AddressSanitizer: heap-use-after-free on address 0x61f0000a03ec at pc 0x14c59b502845 bp 0x14c59ca5e640 sp 0x14c59ca5e630
READ of size 4 at 0x61f0000a03ec thread T28
#0 0x14c59b502844 in ha_spider::lock_tables() /test/10.5_dbg_san/storage/spider/ha_spider.cc:14859
#1 0x14c59b505652 in ha_spider::external_lock(THD*, int) /test/10.5_dbg_san/storage/spider/ha_spider.cc:1115
#2 0x5637f37cb7ae in handler::ha_external_lock(THD*, int) /test/10.5_dbg_san/sql/handler.cc:6853
#3 0x5637f440a96a in handler::ha_external_unlock(THD*) /test/10.5_dbg_san/sql/handler.h:3392
#4 0x5637f440a96a in unlock_external /test/10.5_dbg_san/sql/lock.cc:730
#5 0x5637f440b89d in mysql_unlock_tables(THD, st_mysql_lock, bool) /test/10.5_dbg_san/sql/lock.cc:435
#6 0x5637f440ddee in mysql_unlock_tables(THD, st_mysql_lock) /test/10.5_dbg_san/sql/lock.cc:418
#7 0x5637f1dcd515 in close_thread_tables(THD*) /test/10.5_dbg_san/sql/sql_base.cc:930
#8 0x5637f220f6fc in mysql_execute_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:6233
#9 0x5637f2216ce9 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:8221
#10 0x5637f2227084 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:1892
#11 0x5637f223583a in do_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:1376
#12 0x5637f2b29735 in do_handle_one_connection(CONNECT*, bool) /test/10.5_dbg_san/sql/sql_connect.cc:1417
#13 0x5637f2b2ac50 in handle_one_connection /test/10.5_dbg_san/sql/sql_connect.cc:1319
#14 0x14c5c2897ad9 in start_thread nptl/pthread_create.c:444
#15 0x14c5c292847b in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

0x61f0000a03ec is located 364 bytes inside of 3112-byte region [0x61f0000a0280,0x61f0000a0ea8)
freed by thread T28 here:
#0 0x5637f1a18fc7 in __interceptor_free (/test/UBASAN_MD150724-mariadb-10.5.26-linux-x86_64-dbg/bin/mariadbd+0x84effc7)
#1 0x5637f645812f in my_free /test/10.5_dbg_san/mysys/my_malloc.c:213
#2 0x14c59b41d316 in spider_free_mem(st_spider_transaction, void, unsigned long) /test/10.5_dbg_san/storage/spider/spd_malloc.cc:183
#3 0x14c59b348980 in spider_free_conn(st_spider_conn*) /test/10.5_dbg_san/storage/spider/spd_conn.cc:905
#4 0x14c59b36835c in spider_free_conn_from_trx(st_spider_transaction, st_spider_conn, bool, bool, int*) /test/10.5_dbg_san/storage/spider/spd_conn.cc:393
#5 0x14c59b25357e in spider_free_trx_conn(st_spider_transaction*, bool) /test/10.5_dbg_san/storage/spider/spd_trx.cc:122
#6 0x14c59b26948e in spider_rollback(handlerton, THD, bool) /test/10.5_dbg_san/storage/spider/spd_trx.cc:3317
#7 0x5637f37760d2 in ha_rollback_trans(THD*, bool) /test/10.5_dbg_san/sql/handler.cc:2158
#8 0x5637f2bbabbb in trans_rollback_stmt(THD*) /test/10.5_dbg_san/sql/transaction.cc:535
#9 0x5637f220ead8 in mysql_execute_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:6220
#10 0x5637f2216ce9 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:8221
#11 0x5637f2227084 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:1892
#12 0x5637f223583a in do_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:1376
#13 0x5637f2b29735 in do_handle_one_connection(CONNECT*, bool) /test/10.5_dbg_san/sql/sql_connect.cc:1417
#14 0x5637f2b2ac50 in handle_one_connection /test/10.5_dbg_san/sql/sql_connect.cc:1319
#15 0x14c5c2897ad9 in start_thread nptl/pthread_create.c:444

previously allocated by thread T28 here:
#0 0x5637f1a19317 in malloc (/test/UBASAN_MD150724-mariadb-10.5.26-linux-x86_64-dbg/bin/mariadbd+0x84f0317)
#1 0x5637f6457dd1 in my_malloc /test/10.5_dbg_san/mysys/my_malloc.c:91
#2 0x14c59b41d749 in spider_bulk_alloc_mem(st_spider_transaction, unsigned int, char const, char const*, unsigned long, unsigned long, ...) /test/10.5_dbg_san/storage/spider/spd_malloc.cc:231
#3 0x14c59b35dd54 in spider_create_conn(st_spider_share, ha_spider, int, int, unsigned int, int*) /test/10.5_dbg_san/storage/spider/spd_conn.cc:434
#4 0x14c59b36438c in spider_get_conn(st_spider_share, int, char, st_spider_transaction, ha_spider, bool, bool, unsigned int, int*) /test/10.5_dbg_san/storage/spider/spd_conn.cc:798
#5 0x14c59b3d004c in spider_get_share(char const, TABLE, THD, ha_spider, int*) /test/10.5_dbg_san/storage/spider/spd_table.cc:4711
#6 0x14c59b4d2710 in ha_spider::open(char const*, int, unsigned int) /test/10.5_dbg_san/storage/spider/ha_spider.cc:397
#7 0x5637f378575d in handler::ha_open(TABLE, char const, int, unsigned int, st_mem_root, List<String>) /test/10.5_dbg_san/sql/handler.cc:3103
#8 0x5637f297d659 in open_table_from_share(THD, TABLE_SHARE, st_mysql_const_lex_string const, unsigned int, unsigned int, unsigned int, TABLE, bool, List<String>*) /test/10.5_dbg_san/sql/table.cc:4319
#9 0x5637f1ddc095 in open_table(THD, TABLE_LIST, Open_table_context*) /test/10.5_dbg_san/sql/sql_base.cc:2024
#10 0x5637f1df0675 in open_and_process_table /test/10.5_dbg_san/sql/sql_base.cc:3819
#11 0x5637f1df0675 in open_tables(THD, DDL_options_st const&, TABLE_LIST, unsigned int, unsigned int, Prelocking_strategy*) /test/10.5_dbg_san/sql/sql_base.cc:4303
#12 0x5637f1df8fd7 in open_and_lock_tables(THD, DDL_options_st const&, TABLE_LIST, bool, unsigned int, Prelocking_strategy*) /test/10.5_dbg_san/sql/sql_base.cc:5250
#13 0x5637f2180e9d in open_and_lock_tables(THD, TABLE_LIST, bool, unsigned int) /test/10.5_dbg_san/sql/sql_base.h:509
#14 0x5637f2180e9d in execute_sqlcom_select /test/10.5_dbg_san/sql/sql_parse.cc:6346
#15 0x5637f21e865f in mysql_execute_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:4030
#16 0x5637f2216ce9 in mysql_parse(THD, char, unsigned int, Parser_state*, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:8221
#17 0x5637f2227084 in dispatch_command(enum_server_command, THD, char, unsigned int, bool, bool) /test/10.5_dbg_san/sql/sql_parse.cc:1892
#18 0x5637f223583a in do_command(THD*) /test/10.5_dbg_san/sql/sql_parse.cc:1376
#19 0x5637f2b29735 in do_handle_one_connection(CONNECT*, bool) /test/10.5_dbg_san/sql/sql_connect.cc:1417
#20 0x5637f2b2ac50 in handle_one_connection /test/10.5_dbg_san/sql/sql_connect.cc:1319
#21 0x14c5c2897ad9 in start_thread nptl/pthread_create.c:444

Thread T28 created by T0 here:
#0 0x5637f19bd135 in pthread_create (/test/UBASAN_MD150724-mariadb-10.5.26-linux-x86_64-dbg/bin/mariadbd+0x8494135)
#1 0x5637f1a73d12 in create_thread_to_handle_connection(CONNECT*) /test/10.5_dbg_san/sql/mysqld.cc:6108
#2 0x5637f1a7f72a in create_new_thread(CONNECT*) /test/10.5_dbg_san/sql/mysqld.cc:6167
#3 0x5637f1a7fe52 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /test/10.5_dbg_san/sql/mysqld.cc:6232
#4 0x5637f1a80cd4 in handle_connections_sockets() /test/10.5_dbg_san/sql/mysqld.cc:6359
#5 0x5637f1a87a7b in mysqld_main(int, char**) /test/10.5_dbg_san/sql/mysqld.cc:5754
#6 0x5637f1a5eeba in main /test/10.5_dbg_san/sql/main.cc:25
#7 0x14c5c28280cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: heap-use-after-free /test/10.5_dbg_san/storage/spider/ha_spider.cc:14859 in ha_spider::lock_tables()
Shadow bytes around the buggy address:
0x0c3e8000c020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3e8000c030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3e8000c040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c3e8000c050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e8000c060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c3e8000c070: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd
0x0c3e8000c080: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e8000c090: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e8000c0a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e8000c0b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c3e8000c0c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==205432==ABORTING

Present in 10.6+. Seems to be very lightly sporadic (~1 in 10 times not reproducible).

Attachments

Issue Links

relates to

MDEV-29962 SIGSEGV in ha_spider::lock_tables on BEGIN after table lock

Closed

MDEV-30014 heap-use-after-free in ha_spider::lock_tables(), highly sporadic SIGSEGV in intern_close_table

Closed

Activity

Ascending order - Click to sort in descending order

Roel Van de Paar added a comment - 2024-07-15 03:57 - edited

Confirmed that the heap-use-after-free in ha_spider::lock_tables exists in a 10.5 trunk build (@ 3c508d4c71c8bf27c6ecceba53ab9d4325a1bd6c) as of today, whereas the bug in this ticket is 10.6+ only, which means that the ASAN warning may be unrelated to this ticket and be ~~MDEV-29962~~ instead.

Roel Van de Paar added a comment - 2024-07-15 03:57 - edited Confirmed that the heap-use-after-free in ha_spider::lock_tables exists in a 10.5 trunk build (@ 3c508d4c71c8bf27c6ecceba53ab9d4325a1bd6c ) as of today, whereas the bug in this ticket is 10.6+ only, which means that the ASAN warning may be unrelated to this ticket and be MDEV-29962 instead.

Yuchen Pei added a comment - 2024-07-16 05:25

With the following mtr testcase (placed under spider/bugfix) at 11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063, I could get ASAN use-after-free, but not segv. Without ASAN it passes. With ASAN and the ~~MDEV-29962~~, it also passes:

--disable_query_log

--disable_result_log

--source ../../t/test_init.inc

--enable_result_log

--enable_query_log

set spider_same_server_link= 1;

evalp CREATE SERVER srv FOREIGN DATA WRAPPER mysql

OPTIONS (SOCKET "$MASTER_1_MYSOCK", DATABASE 'test',user 'root');

SET spider_same_server_link=1;

CREATE TABLE t1 (c1 INT) ENGINE=InnoDB;

CREATE TABLE t2 (c1 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"';

CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider;

SELECT * FROM t2;

--error 1429

SELECT * FROM t3;

LOCK TABLES t2 WRITE;

--error 12622

ALTER TABLE t2 CHANGE c1 c1 DOUBLE;

# crash site

--error 1136

INSERT INTO t3 VALUES (1);

--disable_query_log

--disable_result_log

--source ../../t/test_deinit.inc

--enable_result_log

--enable_query_log

Yuchen Pei added a comment - 2024-07-16 05:25 With the following mtr testcase (placed under spider/bugfix) at 11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063, I could get ASAN use-after-free, but not segv. Without ASAN it passes. With ASAN and the MDEV-29962 , it also passes: --disable_query_log --disable_result_log --source ../../t/test_init.inc --enable_result_log --enable_query_log set spider_same_server_link= 1; evalp CREATE SERVER srv FOREIGN DATA WRAPPER mysql OPTIONS (SOCKET "$MASTER_1_MYSOCK" , DATABASE 'test' , user 'root' ); SET spider_same_server_link=1; CREATE TABLE t1 (c1 INT ) ENGINE=InnoDB; CREATE TABLE t2 (c1 INT ) ENGINE=Spider COMMENT= 'WRAPPER "mysql",SRV "srv",TABLE "t1"' ; CREATE TABLE t3 (c1 INT ,c2 INT ) ENGINE=Spider; SELECT * FROM t2; --error 1429 SELECT * FROM t3; LOCK TABLES t2 WRITE; --error 12622 ALTER TABLE t2 CHANGE c1 c1 DOUBLE ; # crash site --error 1136 INSERT INTO t3 VALUES (1); --disable_query_log --disable_result_log --source ../../t/test_deinit.inc --enable_result_log --enable_query_log

Roel Van de Paar added a comment - 2024-07-16 21:14

I tested this further and had some interesting results: pasting the testcase at the CLI with a fresh server, I had no crash four times, and each time the final query would result in ERROR 1136 (21S01): Column count doesn't match value count at row 1.

However, when placing the same in a SQL file in.sql and SOURCE-ing the same from the client, it crashed immediately, repeatable with a fresh instance each time, also four times.

I then tried the same under MTR, i.e.

./mtr --start-and-exit --mysqld=--innodb

../bin/mariadb -P19000 -h127.0.0.1 -uroot

MariaDB [test]> use test

MariaDB [test]> source ../in.sql

However, this results in not crashing and the ERROR 1136. The reason for this would be likely the socket, so I changed in.sql to use the MTR socket:

INSTALL PLUGIN Spider SONAME 'ha_spider.so';

CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET 'var/tmp/mysqld.1.sock',DATABASE'',USER'',PASSWORD'');

CREATE TABLE t1 (c1 INT) ENGINE=InnoDB;

CREATE TABLE t2 (c1 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"';

CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider;

SELECT * FROM t2;

SELECT * FROM t3;

LOCK TABLES t2 WRITE;

ALTER TABLE t2 CHANGE c1 c1 DOUBLE;

INSERT INTO t3 VALUES (1);

However, this still did not crash using SOURCE inside an MTR started instance. Comparing the output between the client we see a clear difference in the output (the only changed item in.sql is the socket location):

11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063 (Debug) CLIENT
11.2.5-dbg>source in.sql
Query OK, 0 rows affected (0.587 sec)

Query OK, 0 rows affected (0.001 sec)

Query OK, 0 rows affected (0.006 sec)

Query OK, 0 rows affected (0.004 sec)

Query OK, 0 rows affected (0.003 sec)

Empty set (0.002 sec)

--------------
SELECT * FROM t3
--------------

ERROR 1429 (HY000) at line 7 in file: 'in_nw.sql': Unable to connect to foreign data source: localhost
Query OK, 0 rows affected (0.001 sec)

--------------
ALTER TABLE t2 CHANGE c1 c1 DOUBLE
--------------

ERROR 12622 (HY000) at line 9 in file: 'in_nw.sql': Can't use this operation before executing 'unlock tables'
--------------
INSERT INTO t3 VALUES (1)
--------------

ERROR 2013 (HY000) at line 10 in file: 'in_nw.sql': Lost connection to server during query

Versus MTR:

11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063 (Debug) CLIENT
MariaDB [(none)]> use test
Database changed
MariaDB [test]> source ../in.sql
Query OK, 0 rows affected (0.072 sec)

Query OK, 0 rows affected (0.000 sec)

Query OK, 0 rows affected (0.003 sec)

Query OK, 0 rows affected (0.001 sec)

Query OK, 0 rows affected (0.000 sec)

--------------
SELECT * FROM t2
--------------

ERROR 1429 (HY000) at line 6 in file: '../in.sql': Unable to connect to foreign data source: srv
--------------
SELECT * FROM t3
--------------

ERROR 1429 (HY000) at line 7 in file: '../in.sql': Unable to connect to foreign data source: localhost
--------------
LOCK TABLES t2 WRITE
--------------

ERROR 1429 (HY000) at line 8 in file: '../in.sql': Unable to connect to foreign data source: srv
Query OK, 0 rows affected (0.002 sec)
Records: 0 Duplicates: 0 Warnings: 0

--------------
INSERT INTO t3 VALUES (1)
--------------

ERROR 1136 (21S01) at line 10 in file: '../in.sql': Column count doesn't match value count at row 1

Notice how the SELECT * FROM t2; succeeds in the client, and how there is a error 12622 at line 9 in the CLI vs 1429 on line 8 in MTR.

There is something substantially different between the CLI and CLI-via-MTR. It is not InnoDB availability (addressed by --mysqld option), nor spider_same_server_link (I tested with that one used in MTR also).

I have run into this situation with some regularity, and it would be great to figure out what is causing the difference as this would simplify translating CLI testcases to MTR or CLI-via-MTR and increase overall reproducibility of issues.

Roel Van de Paar added a comment - 2024-07-16 21:14 I tested this further and had some interesting results: pasting the testcase at the CLI with a fresh server, I had no crash four times, and each time the final query would result in ERROR 1136 (21S01): Column count doesn't match value count at row 1 . However, when placing the same in a SQL file in.sql and SOURCE -ing the same from the client, it crashed immediately, repeatable with a fresh instance each time, also four times. I then tried the same under MTR, i.e. . /mtr --start-and- exit --mysqld=--innodb .. /bin/mariadb -P19000 -h127.0.0.1 -uroot MariaDB [ test ]> use test MariaDB [ test ]> source .. /in .sql However, this results in not crashing and the ERROR 1136 . The reason for this would be likely the socket, so I changed in.sql to use the MTR socket: INSTALL PLUGIN Spider SONAME 'ha_spider.so' ; CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET 'var/tmp/mysqld.1.sock' , DATABASE '' , USER '' , PASSWORD '' ); CREATE TABLE t1 (c1 INT ) ENGINE=InnoDB; CREATE TABLE t2 (c1 INT ) ENGINE=Spider COMMENT= 'WRAPPER "mysql",SRV "srv",TABLE "t1"' ; CREATE TABLE t3 (c1 INT ,c2 INT ) ENGINE=Spider; SELECT * FROM t2; SELECT * FROM t3; LOCK TABLES t2 WRITE; ALTER TABLE t2 CHANGE c1 c1 DOUBLE ; INSERT INTO t3 VALUES (1); However, this still did not crash using SOURCE inside an MTR started instance. Comparing the output between the client we see a clear difference in the output (the only changed item in.sql is the socket location): 11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063 (Debug) CLIENT 11.2.5-dbg>source in.sql Query OK, 0 rows affected (0.587 sec) Query OK, 0 rows affected (0.001 sec) Query OK, 0 rows affected (0.006 sec) Query OK, 0 rows affected (0.004 sec) Query OK, 0 rows affected (0.003 sec) Empty set (0.002 sec) -------------- SELECT * FROM t3 -------------- ERROR 1429 (HY000) at line 7 in file: 'in_nw.sql': Unable to connect to foreign data source: localhost Query OK, 0 rows affected (0.001 sec) -------------- ALTER TABLE t2 CHANGE c1 c1 DOUBLE -------------- ERROR 12622 (HY000) at line 9 in file: 'in_nw.sql': Can't use this operation before executing 'unlock tables' -------------- INSERT INTO t3 VALUES (1) -------------- ERROR 2013 (HY000) at line 10 in file: 'in_nw.sql': Lost connection to server during query Versus MTR: 11.2.5 a21e49cbcc5f4adb1a1b4970ceead6a85e968063 (Debug) CLIENT MariaDB [(none)]> use test Database changed MariaDB [test]> source ../in.sql Query OK, 0 rows affected (0.072 sec) Query OK, 0 rows affected (0.000 sec) Query OK, 0 rows affected (0.003 sec) Query OK, 0 rows affected (0.001 sec) Query OK, 0 rows affected (0.000 sec) -------------- SELECT * FROM t2 -------------- ERROR 1429 (HY000) at line 6 in file: '../in.sql': Unable to connect to foreign data source: srv -------------- SELECT * FROM t3 -------------- ERROR 1429 (HY000) at line 7 in file: '../in.sql': Unable to connect to foreign data source: localhost -------------- LOCK TABLES t2 WRITE -------------- ERROR 1429 (HY000) at line 8 in file: '../in.sql': Unable to connect to foreign data source: srv Query OK, 0 rows affected (0.002 sec) Records: 0 Duplicates: 0 Warnings: 0 -------------- INSERT INTO t3 VALUES (1) -------------- ERROR 1136 (21S01) at line 10 in file: '../in.sql': Column count doesn't match value count at row 1 Notice how the SELECT * FROM t2; succeeds in the client, and how there is a error 12622 at line 9 in the CLI vs 1429 on line 8 in MTR. There is something substantially different between the CLI and CLI-via-MTR. It is not InnoDB availability (addressed by --mysqld option), nor spider_same_server_link (I tested with that one used in MTR also). I have run into this situation with some regularity, and it would be great to figure out what is causing the difference as this would simplify translating CLI testcases to MTR or CLI-via-MTR and increase overall reproducibility of issues.

Roel Van de Paar added a comment - 2024-07-16 21:26 - edited

Interestingly, the SIGSEGV no longer reproduces on 10.6 dbg @ e644e130b0f8236826b372d81f7fb214ba0a3e5f, build today.

Roel Van de Paar added a comment - 2024-07-16 21:26 - edited Interestingly, the SIGSEGV no longer reproduces on 10.6 dbg @ e644e130b0f8236826b372d81f7fb214ba0a3e5f, build today.

Roel Van de Paar added a comment - 2024-07-16 21:31

Thinking further on the above, why does the SELECT * FROM t2; work in the CLI?

The SELECT can be made to work in MTR also, but the setup is very different as it requires a correct svr definition, user creation and spider_same_server_link=1, whereas in the client we just have the (invalid) DATABASE'',USER'',PASSWORD''.

--source include/have_innodb.inc

--let $SOCKET=`SELECT @@global.socket`

INSTALL PLUGIN Spider SONAME 'ha_spider.so';

CREATE USER spider@localhost IDENTIFIED BY 'pwd';

GRANT ALL ON test.* TO spider@localhost;

eval CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET "$SOCKET",DATABASE 'test',USER 'spider',PASSWORD 'pwd');

SET spider_same_server_link=1;

CREATE TABLE t1 (c1 INT) ENGINE=InnoDB;

CREATE TABLE t2 (c1 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"';

CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider;

SELECT * FROM t2;

--error 1429

SELECT * FROM t3;

LOCK TABLES t2 WRITE;

--error 12622

ALTER TABLE t2 CHANGE c1 c1 DOUBLE;

INSERT INTO t3 VALUES (1);

Roel Van de Paar added a comment - 2024-07-16 21:31 Thinking further on the above, why does the SELECT * FROM t2; work in the CLI? The SELECT can be made to work in MTR also, but the setup is very different as it requires a correct svr definition, user creation and spider_same_server_link=1, whereas in the client we just have the (invalid) DATABASE'',USER'',PASSWORD'' . --source include/have_innodb.inc --let $SOCKET=`SELECT @@global.socket` INSTALL PLUGIN Spider SONAME 'ha_spider.so' ; CREATE USER spider@localhost IDENTIFIED BY 'pwd' ; GRANT ALL ON test.* TO spider@localhost; eval CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET "$SOCKET" , DATABASE 'test' , USER 'spider' , PASSWORD 'pwd' ); SET spider_same_server_link=1; CREATE TABLE t1 (c1 INT ) ENGINE=InnoDB; CREATE TABLE t2 (c1 INT ) ENGINE=Spider COMMENT= 'WRAPPER "mysql",SRV "srv",TABLE "t1"' ; CREATE TABLE t3 (c1 INT ,c2 INT ) ENGINE=Spider; SELECT * FROM t2; --error 1429 SELECT * FROM t3; LOCK TABLES t2 WRITE; --error 12622 ALTER TABLE t2 CHANGE c1 c1 DOUBLE ; INSERT INTO t3 VALUES (1);

Roel Van de Paar added a comment - 2024-07-18 22:30

I was able to reproduce the issue now in 10.6 @ e644e130b0f8236826b372d81f7fb214ba0a3e5f (build 17/7 but not containing the ~~MDEV-29962~~ yet as per git branch -r --contain 0bb9862888567a5304aec18e85bf6dd002fc25d3). However, a st-10.6-merge dbg build as of 19/7, which does contain the fix for ~~MDEV-29962~~, did not reproduce the issue in the same way. It thus looks like ~~MDEV-29962~~ may have also resolved this bug.

Closing ftm, and when the SIGSEGV is re-observed I will re-open.

Roel Van de Paar added a comment - 2024-07-18 22:30 I was able to reproduce the issue now in 10.6 @ e644e130b0f8236826b372d81f7fb214ba0a3e5f (build 17/7 but not containing the MDEV-29962 yet as per git branch -r --contain 0bb9862888567a5304aec18e85bf6dd002fc25d3 ). However, a st-10.6-merge dbg build as of 19/7, which does contain the fix for MDEV-29962 , did not reproduce the issue in the same way. It thus looks like MDEV-29962 may have also resolved this bug. Closing ftm, and when the SIGSEGV is re-observed I will re-open.

People

Assignee:: Unassigned

Reporter:: Roel Van de Paar

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: 2024-07-15 03:49

Updated:: 2024-07-23 07:06

Resolved:: 2024-07-18 22:02

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server