These warnings that danblack mentioned are a permission for GCC 8 or later may optimize away checks for null pointers, similar to MDEV-15587:
/home/dan/mariadb-server-not-worktree/sql/protocol.cc:61:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/mf_iocache.c:772:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/my_alloc.c:468:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/sql/sql_string.h:329:11: runtime error: null pointer passed as argument 2, which is declared to never be null
In fact, today I built a 10.2 -DWITH_ASAN=ON debug build on GCC 10.1, using -O2 -march=native -mtune=native, and I got SIGSEGV in 3 tests. One of them was the following, extracted from main.view:
CREATEVIEW v1 ASSELECT ENCRYPT("dhgdhgd");
disable_result_log;
SELECT * FROM v1;
The following patch alone did not fix it:
--- sql/sql_string.h
+++ sql/sql_string.h
@@ -555,7 +555,8 @@
}
void q_append(const char *data, size_t data_len)
{
- memcpy(Ptr + str_length, data, data_len);
+ if (data_len)
+ memcpy(Ptr + str_length, data, data_len);
DBUG_ASSERT(str_length <= UINT_MAX32 - data_len);
str_length += (uint)data_len;
}
I think that the above is necessary, because we do not want GCC to infer that the data parameter is nonnull and allow unsafe optimizations. I saw more WITH_UBSAN warnings for the above 3-line test. Probably more of them should be fixed to fix that crash:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
/mariadb/10.2o/mysys/mf_iocache.c:807:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/mariadb/10.2o/mysys/my_alloc.c:452:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/debug_sync.cc:322:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/sql_string.h:558:11: runtime error: null pointer passed as argument 2, which is declared to never be null
The tests that crashed for me due to this on the WITH_ASAN build were: main.func_encrypt main.func_crypt main.view. Here is one stack trace:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
CURRENT_TEST: main.func_encrypt
mysqltest: At line 103: query 'select encrypt(f1,f2) as a from t1,(select encrypt(f1,f2) as b from t1) a' failed: 2013: Lost connection to MySQL server during query
…
2020-07-31 11:07:32 140373456430016 [Note] /dev/shm/10.2o/sql/mysqld: ready for connections.
Version: '10.2.33-MariaDB-debug-log' socket: '/dev/shm/10.2o/mysql-test/var/tmp/18/mysqld.1.sock' port: 16320 Source distribution
200731 11:07:32 [ERROR] mysqld got signal 11 ;
…
#3 <signal handler called>
#4 0x0000000000000000 in ?? ()
#5 0x0000564d1c00bf9f in Item_func_encrypt::val_str (this=0x62b0000005d8, str=0x7fab33897b20) at /mariadb/10.2o/sql/sql_string.h:229
#6 0x0000564d1be00d61 in Item::send (this=0x62b0000005d8, protocol=0x62a0000607c0, buffer=<optimized out>) at /mariadb/10.2o/sql/item.cc:6900
#7 0x0000564d1b5bc52f in Protocol::send_result_set_row (this=this@entry=0x62a0000607c0, row_items=row_items@entry=0x62a000064668) at /mariadb/10.2o/sql/protocol.cc:990
#8 0x0000564d1b70c697 in select_send::send_data (this=0x62b000002ab8, items=<optimized out>) at /mariadb/10.2o/sql/sql_class.cc:2731
#9 0x0000564d1b8e21ff in end_send (join=0x62b000002ae0, join_tab=0x62b000005358, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:20045
#10 0x0000564d1bbaca6c in JOIN_CACHE::generate_full_extensions (this=0x62b000005cc8, rec_ptr=0x7fab3350a819 "\374\066\302\r") at /mariadb/10.2o/sql/sql_join_cache.cc:2401
#11 0x0000564d1bbad358 in JOIN_CACHE::join_matching_records (this=0x62b000005cc8, skip_last=<optimized out>) at /mariadb/10.2o/sql/sql_join_cache.cc:2293
#12 0x0000564d1bbac284 in JOIN_CACHE::join_records (this=this@entry=0x62b000005cc8, skip_last=skip_last@entry=false) at /mariadb/10.2o/sql/sql_join_cache.cc:2087
#13 0x0000564d1b88e65a in sub_select_cache (join=0x62b000002ae0, join_tab=0x62b000004fa8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18652
#14 0x0000564d1b88d460 in sub_select (join=0x62b000002ae0, join_tab=0x62b000004bf8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18823
#15 0x0000564d1b929ab2 in do_select (procedure=<optimized out>, join=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:18419
#16 JOIN::exec_inner (this=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3638
#17 0x0000564d1b92b57a in JOIN::exec (this=this@entry=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3433
#19 0x0000564d1b9262c1 in handle_select (thd=thd@entry=0x62a000060208, lex=lex@entry=0x62a000063d40, result=result@entry=0x62b000002ab8, setup_tables_done_option=setup_tables_done_option@entry=0) at /mariadb/10.2o/sql/sql_select.cc:361
#20 0x0000564d1b7a9e3f in execute_sqlcom_select (thd=0x62a000060208, all_tables=<optimized out>) at /mariadb/10.2o/sql/sql_parse.cc:6218
#21 0x0000564d1b7d3d64 in mysql_execute_command (thd=0x62a000060208) at /mariadb/10.2o/sql/sql_parse.cc:3524
Marko Mäkelä
added a comment - These warnings that danblack mentioned are a permission for GCC 8 or later may optimize away checks for null pointers, similar to MDEV-15587 :
/home/dan/mariadb-server-not-worktree/sql/protocol.cc:61:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/mf_iocache.c:772:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/my_alloc.c:468:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/sql/sql_string.h:329:11: runtime error: null pointer passed as argument 2, which is declared to never be null
In fact, today I built a 10.2 -DWITH_ASAN=ON debug build on GCC 10.1, using -O2 -march=native -mtune=native , and I got SIGSEGV in 3 tests. One of them was the following, extracted from main.view :
CREATE VIEW v1 AS SELECT ENCRYPT( "dhgdhgd" );
disable_result_log;
SELECT * FROM v1;
The following patch alone did not fix it:
--- sql/sql_string.h
+++ sql/sql_string.h
@@ -555,7 +555,8 @@
}
void q_append(const char *data, size_t data_len)
{
- memcpy(Ptr + str_length, data, data_len);
+ if (data_len)
+ memcpy(Ptr + str_length, data, data_len);
DBUG_ASSERT(str_length <= UINT_MAX32 - data_len);
str_length += (uint)data_len;
}
I think that the above is necessary, because we do not want GCC to infer that the data parameter is nonnull and allow unsafe optimizations. I saw more WITH_UBSAN warnings for the above 3-line test. Probably more of them should be fixed to fix that crash:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
/mariadb/10.2o/mysys/mf_iocache.c:807:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/mariadb/10.2o/mysys/my_alloc.c:452:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/debug_sync.cc:322:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/sql_string.h:558:11: runtime error: null pointer passed as argument 2, which is declared to never be null
The tests that crashed for me due to this on the WITH_ASAN build were: main.func_encrypt main.func_crypt main.view . Here is one stack trace:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
CURRENT_TEST: main.func_encrypt
mysqltest: At line 103: query 'select encrypt(f1,f2) as a from t1,(select encrypt(f1,f2) as b from t1) a' failed: 2013: Lost connection to MySQL server during query
…
2020-07-31 11:07:32 140373456430016 [Note] /dev/shm/10.2o/sql/mysqld: ready for connections.
Version: '10.2.33-MariaDB-debug-log' socket: '/dev/shm/10.2o/mysql-test/var/tmp/18/mysqld.1.sock' port: 16320 Source distribution
200731 11:07:32 [ERROR] mysqld got signal 11 ;
…
#3 <signal handler called>
#4 0x0000000000000000 in ?? ()
#5 0x0000564d1c00bf9f in Item_func_encrypt::val_str (this=0x62b0000005d8, str=0x7fab33897b20) at /mariadb/10.2o/sql/sql_string.h:229
#6 0x0000564d1be00d61 in Item::send (this=0x62b0000005d8, protocol=0x62a0000607c0, buffer=<optimized out>) at /mariadb/10.2o/sql/item.cc:6900
#7 0x0000564d1b5bc52f in Protocol::send_result_set_row (this=this@entry=0x62a0000607c0, row_items=row_items@entry=0x62a000064668) at /mariadb/10.2o/sql/protocol.cc:990
#8 0x0000564d1b70c697 in select_send::send_data (this=0x62b000002ab8, items=<optimized out>) at /mariadb/10.2o/sql/sql_class.cc:2731
#9 0x0000564d1b8e21ff in end_send (join=0x62b000002ae0, join_tab=0x62b000005358, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:20045
#10 0x0000564d1bbaca6c in JOIN_CACHE::generate_full_extensions (this=0x62b000005cc8, rec_ptr=0x7fab3350a819 "\374\066\302\r") at /mariadb/10.2o/sql/sql_join_cache.cc:2401
#11 0x0000564d1bbad358 in JOIN_CACHE::join_matching_records (this=0x62b000005cc8, skip_last=<optimized out>) at /mariadb/10.2o/sql/sql_join_cache.cc:2293
#12 0x0000564d1bbac284 in JOIN_CACHE::join_records (this=this@entry=0x62b000005cc8, skip_last=skip_last@entry=false) at /mariadb/10.2o/sql/sql_join_cache.cc:2087
#13 0x0000564d1b88e65a in sub_select_cache (join=0x62b000002ae0, join_tab=0x62b000004fa8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18652
#14 0x0000564d1b88d460 in sub_select (join=0x62b000002ae0, join_tab=0x62b000004bf8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18823
#15 0x0000564d1b929ab2 in do_select (procedure=<optimized out>, join=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:18419
#16 JOIN::exec_inner (this=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3638
#17 0x0000564d1b92b57a in JOIN::exec (this=this@entry=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3433
#18 0x0000564d1b9232fc in mysql_select (thd=0x62a000060208, tables=<optimized out>, wild_num=<optimized out>, fields=<optimized out>, conds=<optimized out>, og_num=<optimized out>, order=<optimized out>, group=<optimized out>, having=<optimized out>, proc_param=<optimized out>, select_options=<optimized out>, result=<optimized out>, unit=<optimized out>, select_lex=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:3833
#19 0x0000564d1b9262c1 in handle_select (thd=thd@entry=0x62a000060208, lex=lex@entry=0x62a000063d40, result=result@entry=0x62b000002ab8, setup_tables_done_option=setup_tables_done_option@entry=0) at /mariadb/10.2o/sql/sql_select.cc:361
#20 0x0000564d1b7a9e3f in execute_sqlcom_select (thd=0x62a000060208, all_tables=<optimized out>) at /mariadb/10.2o/sql/sql_parse.cc:6218
#21 0x0000564d1b7d3d64 in mysql_execute_command (thd=0x62a000060208) at /mariadb/10.2o/sql/sql_parse.cc:3524
Marko Mäkelä
added a comment - I fixed this type of warnings for running the main.view test in 10.1 , except those that occur in extra/yassl/taocrypt/include/block.hpp:108 , by skipping memcpy() calls when the length parameter is 0.
I intend to port those fixes to the earliest applicable versions in the near future. There are plenty of other WITH_UBSAN failures, but with those fixes, the test suite actually completed (with Failed 1883/5458 tests), instead of being aborted abruptly somewhere.
Marko Mäkelä
added a comment - I tried to fix all null pointer violations that were found by big-test, except one that would cause a failure of main.events_restart :
diff --git a/sql/events.cc b/sql/events.cc
index 33ddcdac3cb..5b029b7c54b 100644
--- a/sql/events.cc
+++ b/sql/events.cc
@@ -662,7 +662,8 @@ Events::drop_schema_events(THD *thd, const char *db)
*/
if (event_queue)
event_queue->drop_schema_events(thd, &db_lex);
- db_repository->drop_schema_events(thd, &db_lex);
+ if (db_repository)
+ db_repository->drop_schema_events(thd, &db_lex);
DBUG_VOID_RETURN;
}
I intend to port those fixes to the earliest applicable versions in the near future. There are plenty of other WITH_UBSAN failures, but with those fixes, the test suite actually completed (with Failed 1883/5458 tests ), instead of being aborted abruptly somewhere.
I have pushed this to 10.2 and 10.3. The merges to 10.4 and 10.5 are in progress and will hopefully be pushed tomorrow. There are still numerous other runtime error that cmake -DWITH_UBSAN=ON builds are reporting.
Marko Mäkelä
added a comment - I have pushed this to 10.2 and 10.3. The merges to 10.4 and 10.5 are in progress and will hopefully be pushed tomorrow. There are still numerous other runtime error that cmake -DWITH_UBSAN=ON builds are reporting.
People
Marko Mäkelä
Roel Van de Paar
Votes:
1Vote for this issue
Watchers:
5Start watching this issue
Dates
Created:
Updated:
Resolved:
Git Integration
Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.
These warnings that danblack mentioned are a permission for GCC 8 or later may optimize away checks for null pointers, similar to
MDEV-15587:/home/dan/mariadb-server-not-worktree/sql/protocol.cc:61:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/mf_iocache.c:772:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/home/dan/mariadb-server-not-worktree/mysys/my_alloc.c:468:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/home/dan/mariadb-server-not-worktree/sql/sql_string.h:329:11: runtime error: null pointer passed as argument 2, which is declared to never be null
In fact, today I built a 10.2 -DWITH_ASAN=ON debug build on GCC 10.1, using -O2 -march=native -mtune=native, and I got SIGSEGV in 3 tests. One of them was the following, extracted from main.view:
disable_result_log;
The following patch alone did not fix it:
--- sql/sql_string.h
+++ sql/sql_string.h
@@ -555,7 +555,8 @@
}
void q_append(const char *data, size_t data_len)
{
- memcpy(Ptr + str_length, data, data_len);
+ if (data_len)
+ memcpy(Ptr + str_length, data, data_len);
DBUG_ASSERT(str_length <= UINT_MAX32 - data_len);
str_length += (uint)data_len;
I think that the above is necessary, because we do not want GCC to infer that the data parameter is nonnull and allow unsafe optimizations. I saw more WITH_UBSAN warnings for the above 3-line test. Probably more of them should be fixed to fix that crash:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
/mariadb/10.2o/mysys/mf_iocache.c:807:3: runtime error: null pointer passed as argument 1, which is declared to never be null
/mariadb/10.2o/mysys/my_alloc.c:452:5: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/debug_sync.cc:322:9: runtime error: null pointer passed as argument 2, which is declared to never be null
/mariadb/10.2o/sql/sql_string.h:558:11: runtime error: null pointer passed as argument 2, which is declared to never be null
The tests that crashed for me due to this on the WITH_ASAN build were: main.func_encrypt main.func_crypt main.view. Here is one stack trace:
10.2 8a612314d0c9bc5b1db6f3998f26c28967915949
CURRENT_TEST: main.func_encrypt
mysqltest: At line 103: query 'select encrypt(f1,f2) as a from t1,(select encrypt(f1,f2) as b from t1) a' failed: 2013: Lost connection to MySQL server during query
…
2020-07-31 11:07:32 140373456430016 [Note] /dev/shm/10.2o/sql/mysqld: ready for connections.
Version: '10.2.33-MariaDB-debug-log' socket: '/dev/shm/10.2o/mysql-test/var/tmp/18/mysqld.1.sock' port: 16320 Source distribution
200731 11:07:32 [ERROR] mysqld got signal 11 ;
…
#3 <signal handler called>
#4 0x0000000000000000 in ?? ()
#5 0x0000564d1c00bf9f in Item_func_encrypt::val_str (this=0x62b0000005d8, str=0x7fab33897b20) at /mariadb/10.2o/sql/sql_string.h:229
#6 0x0000564d1be00d61 in Item::send (this=0x62b0000005d8, protocol=0x62a0000607c0, buffer=<optimized out>) at /mariadb/10.2o/sql/item.cc:6900
#7 0x0000564d1b5bc52f in Protocol::send_result_set_row (this=this@entry=0x62a0000607c0, row_items=row_items@entry=0x62a000064668) at /mariadb/10.2o/sql/protocol.cc:990
#8 0x0000564d1b70c697 in select_send::send_data (this=0x62b000002ab8, items=<optimized out>) at /mariadb/10.2o/sql/sql_class.cc:2731
#9 0x0000564d1b8e21ff in end_send (join=0x62b000002ae0, join_tab=0x62b000005358, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:20045
#10 0x0000564d1bbaca6c in JOIN_CACHE::generate_full_extensions (this=0x62b000005cc8, rec_ptr=0x7fab3350a819 "\374\066\302\r") at /mariadb/10.2o/sql/sql_join_cache.cc:2401
#11 0x0000564d1bbad358 in JOIN_CACHE::join_matching_records (this=0x62b000005cc8, skip_last=<optimized out>) at /mariadb/10.2o/sql/sql_join_cache.cc:2293
#12 0x0000564d1bbac284 in JOIN_CACHE::join_records (this=this@entry=0x62b000005cc8, skip_last=skip_last@entry=false) at /mariadb/10.2o/sql/sql_join_cache.cc:2087
#13 0x0000564d1b88e65a in sub_select_cache (join=0x62b000002ae0, join_tab=0x62b000004fa8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18652
#14 0x0000564d1b88d460 in sub_select (join=0x62b000002ae0, join_tab=0x62b000004bf8, end_of_records=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:18823
#15 0x0000564d1b929ab2 in do_select (procedure=<optimized out>, join=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:18419
#16 JOIN::exec_inner (this=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3638
#17 0x0000564d1b92b57a in JOIN::exec (this=this@entry=0x62b000002ae0) at /mariadb/10.2o/sql/sql_select.cc:3433
#18 0x0000564d1b9232fc in mysql_select (thd=0x62a000060208, tables=<optimized out>, wild_num=<optimized out>, fields=<optimized out>, conds=<optimized out>, og_num=<optimized out>, order=<optimized out>, group=<optimized out>, having=<optimized out>, proc_param=<optimized out>, select_options=<optimized out>, result=<optimized out>, unit=<optimized out>, select_lex=<optimized out>) at /mariadb/10.2o/sql/sql_select.cc:3833
#19 0x0000564d1b9262c1 in handle_select (thd=thd@entry=0x62a000060208, lex=lex@entry=0x62a000063d40, result=result@entry=0x62b000002ab8, setup_tables_done_option=setup_tables_done_option@entry=0) at /mariadb/10.2o/sql/sql_select.cc:361
#20 0x0000564d1b7a9e3f in execute_sqlcom_select (thd=0x62a000060208, all_tables=<optimized out>) at /mariadb/10.2o/sql/sql_parse.cc:6218
#21 0x0000564d1b7d3d64 in mysql_execute_command (thd=0x62a000060208) at /mariadb/10.2o/sql/sql_parse.cc:3524