[MDEV-33191] SIGSEGV in spider_db_delete_all_rows on TRUNCATE, UBSAN: member call on null pointer of type 'struct spider_db_handler' in spider_db_delete_all_rows - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.6, 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4
Fix Version/s: 10.4.33, 10.5.24, 10.6.17, 10.11.7, 11.0.5, 11.1.4, 11.2.3, 11.3.2
Component/s: Storage Engine - Spider
Labels:
- regression-10.6

Description

INSTALL PLUGIN spider SONAME 'ha_spider.so';

CREATE TABLE t2(c INT) ENGINE=InnoDB;  # Same with MyISAM

CREATE TABLE t1(c INT) ENGINE=Spider COMMENT='socket "../socket.sock",table "t2 t3"';

ALTER TABLE t1 ENGINE=Spider;

TRUNCATE TABLE t1;

Leads to:

11.4.0 9bd95e914f3f12d0d9d93e7a1f2c49e6e8841f17 (Optimized)
Core was generated by `/test/MD271223-mariadb-11.4.0-linux-x86_64-opt/bin/mariadbd --no-defaults --cor'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 spider_db_delete_all_rows (spider=spider@entry=0x1508300b38d0)
at /test/11.4_opt/storage/spider/spd_db_conn.cc:6529
[Current thread is 1 (Thread 0x15086c101640 (LWP 1723536))]
(gdb) bt
#0 spider_db_delete_all_rows (spider=spider@entry=0x1508300b38d0) at /test/11.4_opt/storage/spider/spd_db_conn.cc:6529
#1 0x000015085c1910e1 in ha_spider::truncate (this=0x1508300b38d0) at /test/11.4_opt/storage/spider/ha_spider.cc:8315
#2 ha_spider::truncate (this=0x1508300b38d0) at /test/11.4_opt/storage/spider/ha_spider.cc:8296
#3 0x00005579bf76aa8b in Sql_cmd_truncate_table::handler_truncate (this=<optimized out>, thd=0x150830000c68, table_ref=0x150830010bb8, is_tmp_table=<optimized out>) at /test/11.4_opt/sql/sql_truncate.cc:255
#4 0x00005579bf76b820 in Sql_cmd_truncate_table::truncate_table (this=0x1508300112d0, thd=0x150830000c68, table_ref=0x150830010bb8) at /test/11.4_opt/sql/sql_truncate.cc:515
#5 0x00005579bf76b9ee in Sql_cmd_truncate_table::execute (this=0x1508300112d0, thd=0x150830000c68) at /test/11.4_opt/sql/sql_truncate.cc:581
#6 0x00005579bf61d419 in mysql_execute_command (thd=0x150830000c68, is_called_from_prepared_stmt=<optimized out>) at /test/11.4_opt/sql/sql_parse.cc:5738
#7 0x00005579bf61e346 in mysql_parse (thd=0x150830000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/11.4_opt/sql/sql_parse.cc:7748
#8 0x00005579bf620aed in dispatch_command (command=COM_QUERY, thd=0x150830000c68, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/11.4_opt/sql/sql_parse.cc:1992
#9 0x00005579bf6228a0 in do_command (thd=0x150830000c68, blocking=blocking@entry=true) at /test/11.4_opt/sql/sql_parse.cc:1406
#10 0x00005579bf74ca1f in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/11.4_opt/sql/sql_connect.cc:1418
#11 0x00005579bf74cd6d in handle_one_connection (arg=arg@entry=0x5579c2105cb8) at /test/11.4_opt/sql/sql_connect.cc:1320
#12 0x00005579bfaf6561 in pfs_spawn_thread (arg=0x5579c20baeb8) at /test/11.4_opt/storage/perfschema/pfs.cc:2201
#13 0x0000150874c94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x0000150874d26660 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

11.4.0 9bd95e914f3f12d0d9d93e7a1f2c49e6e8841f17 (Debug)
Core was generated by `/test/MD271223-mariadb-11.4.0-linux-x86_64-dbg/bin/mariadbd --no-defaults --max'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 spider_db_delete_all_rows (spider=spider@entry=0x145af8085b80)
at /test/11.4_dbg/storage/spider/spd_db_conn.cc:6529
[Current thread is 1 (Thread 0x145b340e8640 (LWP 1724345))]
(gdb) bt
#0 spider_db_delete_all_rows (spider=spider@entry=0x145af8085b80) at /test/11.4_dbg/storage/spider/spd_db_conn.cc:6529
#1 0x0000145b24182515 in ha_spider::truncate (this=0x145af8085b80) at /test/11.4_dbg/storage/spider/ha_spider.cc:8315
#2 0x00005607cfee2044 in handler::ha_truncate (this=0x145af8085b80) at /test/11.4_dbg/sql/handler.cc:5310
#3 0x00005607cfd740cd in Sql_cmd_truncate_table::handler_truncate (this=this@entry=0x145af8013cd0, thd=thd@entry=0x145af8000d58, table_ref=table_ref@entry=0x145af80135b8, is_tmp_table=is_tmp_table@entry=false) at /test/11.4_dbg/sql/sql_truncate.cc:255
#4 0x00005607cfd74fa7 in Sql_cmd_truncate_table::truncate_table (this=this@entry=0x145af8013cd0, thd=thd@entry=0x145af8000d58, table_ref=table_ref@entry=0x145af80135b8) at /test/11.4_dbg/sql/sql_truncate.cc:515
#5 0x00005607cfd750f2 in Sql_cmd_truncate_table::execute (this=0x145af8013cd0, thd=0x145af8000d58) at /test/11.4_dbg/sql/sql_truncate.cc:581
#6 0x00005607cfbd7130 in mysql_execute_command (thd=thd@entry=0x145af8000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.4_dbg/sql/sql_parse.cc:5738
#7 0x00005607cfbd84bb in mysql_parse (thd=thd@entry=0x145af8000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x145b340e71e0) at /test/11.4_dbg/sql/sql_parse.cc:7748
#8 0x00005607cfbda831 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x145af8000d58, packet=packet@entry=0x145af800b1c9 "TRUNCATE TABLE t1", packet_length=packet_length@entry=17, blocking=blocking@entry=true) at /test/11.4_dbg/sql/sql_class.h:253
#9 0x00005607cfbdc956 in do_command (thd=0x145af8000d58, blocking=blocking@entry=true) at /test/11.4_dbg/sql/sql_parse.cc:1406
#10 0x00005607cfd418b7 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5607d230cc88, put_in_cache=put_in_cache@entry=true) at /test/11.4_dbg/sql/sql_connect.cc:1418
#11 0x00005607cfd41bac in handle_one_connection (arg=arg@entry=0x5607d230cc88) at /test/11.4_dbg/sql/sql_connect.cc:1320
#12 0x00005607d018673a in pfs_spawn_thread (arg=0x5607d22add18) at /test/11.4_dbg/storage/perfschema/pfs.cc:2201
#13 0x0000145b3da94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#14 0x0000145b3db26660 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

11.3.0 126157061b4376496c034a809ea4943e863d1465 (Optimized, UBASAN)
2024-01-06 9:31:33 0 [Note] /test/UBASAN_MD021123-mariadb-11.3.0-linux-x86_64-opt/bin/mariadbd: ready for connections.
Version: '11.3.0-MariaDB' socket: '/test/UBASAN_MD021123-mariadb-11.3.0-linux-x86_64-opt/socket.sock' port: 11043 MariaDB Server
/test/11.3_opt_san/storage/spider/spd_db_conn.cc:6529:49: runtime error: member call on null pointer of type 'struct spider_db_handler'
#0 0x14c8becea46f in spider_db_delete_all_rows(ha_spider*) /test/11.3_opt_san/storage/spider/spd_db_conn.cc:6529
#1 0x14c8bee6143d in ha_spider::truncate() /test/11.3_opt_san/storage/spider/ha_spider.cc:8315
#2 0x563d9094e753 in Sql_cmd_truncate_table::handler_truncate(THD, TABLE_LIST, bool) /test/11.3_opt_san/sql/sql_truncate.cc:255
#3 0x563d90954306 in Sql_cmd_truncate_table::truncate_table(THD, TABLE_LIST) /test/11.3_opt_san/sql/sql_truncate.cc:515
#4 0x563d909553bc in Sql_cmd_truncate_table::execute(THD*) /test/11.3_opt_san/sql/sql_truncate.cc:581
#5 0x563d8fececec in mysql_execute_command(THD*, bool) /test/11.3_opt_san/sql/sql_parse.cc:5734
#6 0x563d8feee302 in mysql_parse(THD, char, unsigned int, Parser_state*) /test/11.3_opt_san/sql/sql_parse.cc:7742
#7 0x563d8fef9925 in dispatch_command(enum_server_command, THD, char, unsigned int, bool) /test/11.3_opt_san/sql/sql_parse.cc:1893
#8 0x563d8ff05698 in do_command(THD*, bool) /test/11.3_opt_san/sql/sql_parse.cc:1406
#9 0x563d90847e0c in do_handle_one_connection(CONNECT*, bool) /test/11.3_opt_san/sql/sql_connect.cc:1418
#10 0x563d9084a40c in handle_one_connection /test/11.3_opt_san/sql/sql_connect.cc:1320
#11 0x14c8e1a94ac2 in start_thread nptl/pthread_create.c:442
#12 0x14c8e1b2665f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f)

240106 9:31:38 [ERROR] mysqld got signal 11 ;

11.3.0 126157061b4376496c034a809ea4943e863d1465 (Debug, UBASAN)
Version: '11.3.0-MariaDB-debug' socket: '/test/UBASAN_MD021123-mariadb-11.3.0-linux-x86_64-dbg/socket.sock' port: 11207 MariaDB Server
/test/11.3_dbg_san/storage/spider/spd_db_conn.cc:6529:49: runtime error: member call on null pointer of type 'struct spider_db_handler'
#0 0x1455ac1052bf in spider_db_delete_all_rows(ha_spider*) /test/11.3_dbg_san/storage/spider/spd_db_conn.cc:6529
#1 0x1455ac27d746 in ha_spider::truncate() /test/11.3_dbg_san/storage/spider/ha_spider.cc:8315
#2 0x5646ed7c0634 in handler::ha_truncate() /test/11.3_dbg_san/sql/handler.cc:5310
#3 0x5646ecacc834 in Sql_cmd_truncate_table::handler_truncate(THD, TABLE_LIST, bool) /test/11.3_dbg_san/sql/sql_truncate.cc:255
#4 0x5646ecad2557 in Sql_cmd_truncate_table::truncate_table(THD, TABLE_LIST) /test/11.3_dbg_san/sql/sql_truncate.cc:515
#5 0x5646ecad2e00 in Sql_cmd_truncate_table::execute(THD*) /test/11.3_dbg_san/sql/sql_truncate.cc:581
#6 0x5646ebf6d0eb in mysql_execute_command(THD*, bool) /test/11.3_dbg_san/sql/sql_parse.cc:5734
#7 0x5646ebf73d9b in mysql_parse(THD, char, unsigned int, Parser_state*) /test/11.3_dbg_san/sql/sql_parse.cc:7742
#8 0x5646ebf83b19 in dispatch_command(enum_server_command, THD, char, unsigned int, bool) /test/11.3_dbg_san/sql/sql_parse.cc:1893
#9 0x5646ebf91b9b in do_command(THD*, bool) /test/11.3_dbg_san/sql/sql_parse.cc:1406
#10 0x5646ec9953ab in do_handle_one_connection(CONNECT*, bool) /test/11.3_dbg_san/sql/sql_connect.cc:1418
#11 0x5646ec9968c6 in handle_one_connection /test/11.3_dbg_san/sql/sql_connect.cc:1320
#12 0x1455cec94ac2 in start_thread nptl/pthread_create.c:442
#13 0x1455ced2665f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f)

240106 9:31:41 [ERROR] mysqld got signal 11 ;

Bug confirmed present in:
MariaDB: 10.6.17 (dbg), 10.6.17 (opt), 10.11.7 (dbg), 10.11.7 (opt), 11.0.5 (dbg), 11.0.5 (opt), 11.1.4 (dbg), 11.1.4 (opt), 11.2.3 (dbg), 11.2.3 (opt), 11.3.2 (dbg), 11.3.2 (opt), 11.4.0 (dbg), 11.4.0 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.4.33 (dbg), 10.4.33 (opt), 10.5.24 (dbg), 10.5.24 (opt)

Attachments

Issue Links

is caused by

MDEV-24424 Unnecessary usage of to_float() for INSERT into the Spider table with float column

Closed

Activity

Ascending order - Click to sort in descending order

Roel Van de Paar added a comment - 2024-01-06 00:29 - edited

Several attempts at converting the testcase to MTR failed. It is readily reproducible at the command line using testcase in the original description.

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

INSTALL PLUGIN spider SONAME 'ha_spider.so';

CREATE TABLE t2(c INT);

SET @@spider_same_server_link=1;

eval CREATE TABLE t1(c INT) ENGINE=Spider COMMENT='socket "$SOCKET",table "t2 t3"';

ALTER TABLE t1 ENGINE=Spider;

--error ER_CONNECT_TO_FOREIGN_DATA_SOURCE   # Should not be required (i.e. should crash instead)

TRUNCATE TABLE t1;

Another example:

--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');

CREATE TABLE t2(c INT);

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

ALTER TABLE t1 ENGINE=Spider;

TRUNCATE TABLE t1;

Results in "ER_NO_SUCH_TABLE (1146): Table 'test.t3' doesn't exist" which is correct.

Roel Van de Paar added a comment - 2024-01-06 00:29 - edited Several attempts at converting the testcase to MTR failed. It is readily reproducible at the command line using testcase in the original description. --let $SOCKET=`SELECT @@global.socket` INSTALL PLUGIN spider SONAME 'ha_spider.so' ; CREATE TABLE t2(c INT ); SET @@spider_same_server_link=1; eval CREATE TABLE t1(c INT ) ENGINE=Spider COMMENT= 'socket "$SOCKET",table "t2 t3"' ; ALTER TABLE t1 ENGINE=Spider; --error ER_CONNECT_TO_FOREIGN_DATA_SOURCE # Should not be required (i.e. should crash instead) TRUNCATE TABLE t1; Another example: --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' ); CREATE TABLE t2(c INT ); eval CREATE TABLE t1(c INT ) ENGINE=Spider COMMENT= 'WRAPPER "mysql",SRV "srv",TABLE "t2 t3"' ; ALTER TABLE t1 ENGINE=Spider; TRUNCATE TABLE t1; Results in "ER_NO_SUCH_TABLE (1146): Table 'test.t3' doesn't exist" which is correct.

Yuchen Pei added a comment - 2024-01-08 04:21 - edited

Indeed reproduction is tricky, and here's my case in the sql client
(10.6 8bd5a3de7f44163deffc2c9cce570a6bee117678):

MariaDB [test]> INSTALL SONAME 'ha_spider';

Query OK, 0 rows affected, 1 warning (0.201 sec)

MariaDB [test]> CREATE TABLE t2(c INT);

Query OK, 0 rows affected (0.004 sec)

MariaDB [test]> set spider_same_server_link=on;

Query OK, 0 rows affected (0.002 sec)

MariaDB [test]> CREATE TABLE t1(c INT) ENGINE=Spider COMMENT='socket "/home/ycp/source/mariadb-server/10.6/build/mysql-test/var/tmp/mysqld.1.sock", user "root", table "t2 t3"';

Query OK, 0 rows affected (0.017 sec)

MariaDB [test]> ALTER TABLE t1 ENGINE=Spider;

Query OK, 0 rows affected (0.015 sec)

Records: 0  Duplicates: 0  Warnings: 0

MariaDB [test]> TRUNCATE TABLE t1;

ERROR 2013 (HY000): Lost connection to server during query

Also if I replace the socket with a relative path
./mysql-test/var/tmp/mysqld.1.sock I get
ERROR 1429 (HY000): Unable to connect to foreign data source: localhost

I also managed to work out an mtr case (on an ASAN+UBSAN build):

INSTALL SONAME 'ha_spider';

set spider_same_server_link=on;

CREATE TABLE t2(c INT);

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

evalp CREATE TABLE t1(c INT) ENGINE=Spider COMMENT='socket "$SOCKET", user "root", table "t2 t3"';

ALTER TABLE t1 ENGINE=Spider;

TRUNCATE TABLE t1;

I can confirm neither ASAN nor UBSAN is needed for reproducing.

Yuchen Pei added a comment - 2024-01-08 04:21 - edited Indeed reproduction is tricky, and here's my case in the sql client (10.6 8bd5a3de7f44163deffc2c9cce570a6bee117678): MariaDB [test]> INSTALL SONAME 'ha_spider'; Query OK, 0 rows affected, 1 warning (0.201 sec) MariaDB [test]> CREATE TABLE t2(c INT); Query OK, 0 rows affected (0.004 sec) MariaDB [test]> set spider_same_server_link=on; Query OK, 0 rows affected (0.002 sec) MariaDB [test]> CREATE TABLE t1(c INT) ENGINE=Spider COMMENT='socket "/home/ycp/source/mariadb-server/10.6/build/mysql-test/var/tmp/mysqld.1.sock", user "root", table "t2 t3"'; Query OK, 0 rows affected (0.017 sec) MariaDB [test]> ALTER TABLE t1 ENGINE=Spider; Query OK, 0 rows affected (0.015 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [test]> TRUNCATE TABLE t1; ERROR 2013 (HY000): Lost connection to server during query Also if I replace the socket with a relative path ./mysql-test/var/tmp/mysqld.1.sock I get ERROR 1429 (HY000): Unable to connect to foreign data source: localhost I also managed to work out an mtr case (on an ASAN+UBSAN build): INSTALL SONAME 'ha_spider' ; set spider_same_server_link= on ; CREATE TABLE t2(c INT ); --let $SOCKET=`SELECT @@global.socket` evalp CREATE TABLE t1(c INT ) ENGINE=Spider COMMENT= 'socket "$SOCKET", user "root", table "t2 t3"' ; ALTER TABLE t1 ENGINE=Spider; TRUNCATE TABLE t1; I can confirm neither ASAN nor UBSAN is needed for reproducing.

Yuchen Pei added a comment - 2024-01-08 06:21 - edited

An initial patch

upstream/bb-10.6-mdev-33191 eabe545e662598164c6bc6a3a0f007001e9b3ff1

MDEV-33191 spider: fix dbton_id when iterating over links

There are two array fields in spider_share with similar names:

share->use_sql_dbton_ids that maps from i to the i-th dbton used by

share. Thus it should be used only when i iterates over all distinct

dbtons used by share.

share->sql_dbton_ids that maps from i to the dbton used by the i-th

link of the share. Thus it should be used only when i iterates over

all links of a share.

We correct instances where share->sql_dbton_ids should be used instead

of share->use_sql_dbton_ids.

Yuchen Pei added a comment - 2024-01-08 06:21 - edited An initial patch upstream/bb-10.6-mdev-33191 eabe545e662598164c6bc6a3a0f007001e9b3ff1 MDEV-33191 spider: fix dbton_id when iterating over links There are two array fields in spider_share with similar names: share->use_sql_dbton_ids that maps from i to the i-th dbton used by share. Thus it should be used only when i iterates over all distinct dbtons used by share. share->sql_dbton_ids that maps from i to the dbton used by the i-th link of the share. Thus it should be used only when i iterates over all links of a share. We correct instances where share->sql_dbton_ids should be used instead of share->use_sql_dbton_ids.

Yuchen Pei added a comment - 2024-01-09 00:22 - edited

The cause of the apparent 10.6 regression is

2f6970ef1c7c0d91b750dea0c1ddd4fd707a54dc

MDEV-24424 Unnecessary usage of to_float() for INSERT into the Spider table with float column

Change default wrapper from mysql to mariadb.

However, the logical inconsistency fixed by my patch above is the
real problem, and exists in 10.4, so it should be applied there.

Yuchen Pei added a comment - 2024-01-09 00:22 - edited The cause of the apparent 10.6 regression is 2f6970ef1c7c0d91b750dea0c1ddd4fd707a54dc MDEV-24424 Unnecessary usage of to_float() for INSERT into the Spider table with float column Change default wrapper from mysql to mariadb. However, the logical inconsistency fixed by my patch above is the real problem, and exists in 10.4, so it should be applied there.

Yuchen Pei added a comment - 2024-01-09 01:00

Hi holyfoot, ptal thanks

upstream/bb-10.4-mdev-33191 3a94dd73afe7a8ebe5652bd30f52e60b3dcdc9d8

MDEV-33191 spider: fix dbton_id when iterating over links

There are two array fields in spider_share with similar names:

share->use_sql_dbton_ids that maps from i to the i-th dbton used by

share. Thus it should be used only when i iterates over all distinct

dbtons used by share.

share->sql_dbton_ids that maps from i to the dbton used by the i-th

link of the share. Thus it should be used only when i iterates over

all links of a share.

We correct instances where share->sql_dbton_ids should be used instead

of share->use_sql_dbton_ids.

See my previous comment on why the fix is on 10.4

Yuchen Pei added a comment - 2024-01-09 01:00 Hi holyfoot , ptal thanks upstream/bb-10.4-mdev-33191 3a94dd73afe7a8ebe5652bd30f52e60b3dcdc9d8 MDEV-33191 spider: fix dbton_id when iterating over links There are two array fields in spider_share with similar names: share->use_sql_dbton_ids that maps from i to the i-th dbton used by share. Thus it should be used only when i iterates over all distinct dbtons used by share. share->sql_dbton_ids that maps from i to the dbton used by the i-th link of the share. Thus it should be used only when i iterates over all links of a share. We correct instances where share->sql_dbton_ids should be used instead of share->use_sql_dbton_ids. See my previous comment on why the fix is on 10.4

Roel Van de Paar added a comment - 2024-01-11 21:37 - edited

Thank you! And this also fixes the member call on null pointer of type 'struct spider_db_handler' in spider_db_delete_all_rows issue, correct?

Roel Van de Paar added a comment - 2024-01-11 21:37 - edited Thank you! And this also fixes the member call on null pointer of type 'struct spider_db_handler' in spider_db_delete_all_rows issue, correct?

Yuchen Pei added a comment - 2024-01-12 00:10

> And this also fixes the member call on null pointer of type 'struct spider_db_handler' in spider_db_delete_all_rows issue, correct?

Which one? If you mean the main issue in this ticket, then yes (but
then I don't get the "also" part).

Yuchen Pei added a comment - 2024-01-12 00:10 > And this also fixes the member call on null pointer of type 'struct spider_db_handler' in spider_db_delete_all_rows issue, correct? Which one? If you mean the main issue in this ticket, then yes (but then I don't get the "also" part).

Roel Van de Paar added a comment - 2024-01-12 04:38

ycp Both: 1) the opt/dbg crashes as well as 2) the opt/dbg UBSAN issue.

Roel Van de Paar added a comment - 2024-01-12 04:38 ycp Both: 1) the opt/dbg crashes as well as 2) the opt/dbg UBSAN issue.

Yuchen Pei added a comment - 2024-01-15 22:46

Roel ok I believe these would all be fixed by the patch

Yuchen Pei added a comment - 2024-01-15 22:46 Roel ok I believe these would all be fixed by the patch

Roel Van de Paar added a comment - 2024-01-16 23:29

Ack, thank you!

Roel Van de Paar added a comment - 2024-01-16 23:29 Ack, thank you!

Alexey Botchkov added a comment - 2024-01-24 13:27

ok to push.

Alexey Botchkov added a comment - 2024-01-24 13:27 ok to push.

Yuchen Pei added a comment - 2024-01-25 05:39

pushed 1070575a890ad5fa52af01297b439073f63846a5 to 10.4

Yuchen Pei added a comment - 2024-01-25 05:39 pushed 1070575a890ad5fa52af01297b439073f63846a5 to 10.4

People

Assignee:: Yuchen Pei

Reporter:: Roel Van de Paar

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2024-01-05 22:36

Updated:: 2024-01-28 23:59

Resolved:: 2024-01-25 05:39

Git Integration

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

MariaDB Server