Since MariaDB 10.4.19 most tests succeed when the code is compiled with GCC 9 or 10 and cmake -DWITH_UBSAN (and UBSAN is not instructed to crash on errors by setting an environment variable). But, a clang build would crash on bootstrap, due to dereferencing an invalid constant pointer:
10.4
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==619510==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000010 (pc 0x0000006de2b4 bp 0x000200000000 sp 0x7ffe3fc3bbc0 T619510)
==619510==The signal is caused by a READ memory access.
==619510==Hint: address points to the zero page.
#0 0x6de2b4 in __cxx_global_var_init.1130 /mariadb/10.4/sql/sys_vars.cc:5256:8
#1 0x6de2b4 in _GLOBAL__sub_I_sys_vars.cc /mariadb/10.4/sql/sys_vars.cc
#2 0x23fc874 in __libc_csu_init (/dev/shm/10.4/sql/mysqld+0x23fc874)
#3 0x7fdedcfb8c99 in __libc_start_main csu/../csu/libc-start.c:264:6
#4 0x6ee309 in _start (/dev/shm/10.4/sql/mysqld+0x6ee309)
The crashing instruction is attempting to dereference an invalid constant pointer:
If applying any offset to the null pointer is undefined behaviour, then surely also applying an offset to an invalid constant pointer should be undefined behaviour:
"slave_skip_errors", "Tells the slave thread to continue "
With this patch, clang-12 is reporting some errors that are not reported by GCC 10.2.1:
main.func_math [ fail ] Found warnings/errors in server log file!
Test ended at 2021-07-29 10:12:13
line
/mariadb/10.4/strings/ctype.c:1151:46: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/strings/ctype.c:1151:46 in
/mariadb/10.4/sql/sql_select.cc:3766:22: runtime error: applying non-zero offset 4020089388120 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/sql/sql_select.cc:3766:22 in
/mariadb/10.4/sql/sql_select.cc:3225:32: runtime error: applying non-zero offset 936 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/sql/sql_select.cc:3225:32 in
/mariadb/10.4/sql/sql_show.cc:3828:7: runtime error: call to function rpl_semi_sync_master_show_clients(THD*, st_mysql_show_var*, char*) through pointer to incorrect function type 'int (*)(THD *, st_mysql_show_var *, void *, system_status_var *, enum_var_type)'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/sql/sql_show.cc:3828:7 in
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/strings/decimal.c:1161:8 in
/mariadb/10.4/strings/json_lib.c:1688:26: runtime error: index -1 out of bounds for type 'json_path_step_t [32]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /mariadb/10.4/strings/json_lib.c:1688:26 in
^ Found warnings in /dev/shm/10.4/mysql-test/var/log/mysqld.1.err
Attachments
Issue Links
blocks
MDEV-33157runtime error: call to function wsrep_plugin_init(void*) through pointer to incorrect function type
Closed
MDEV-33158The macro MYSQL_THDVAR_ULONG leads to undefined behaviour, calling mysql_sys_var_long
MDEV-26814UBSAN: runtime error: applying non-zero offset 18446744073709551584 to null pointer on JSON_ARRAY_INSERT, runtime error: pointer index expression with base 0x000000000001 overflowed to 0xffffffffffffffe1
MDEV-34187On startup: UBSAN: runtime error: applying zero offset to null pointer in skip_trailing_space and my_hash_sort_utf8mb3_general1400_nopad_as_ci
MY_LOCALE turns out to have standard layout as well
PFS_events_statements was trivially transformed to standard layout by moving the base class to a data member.
With a small test program you can easily experiment when offsetof is not allowed. https://godbolt.org offers convenient access to many compilers, including GCC 4.8.5, which is the oldest that we currently support.
Apart from Master_info, which is the antagonist in this bug, we have a number of data types on which my_offsetof() is being invoked and offsetof() cannot be invoked due to non-standard layout:
Table_triggers_list
TABLE_LIST
ACL_ROLE
ACL_USER_BASE
These classes either derive from a base class (similar to how PFS_events_statements did before my cleanup) or they encapsulate nonstandard-layout objects, such as List<String>.
Marko Mäkelä
added a comment - Because my_offsetof() appears to exercise undefined pointer arithmetics, we’d better replace it with the standard macro offsetof() where possible:
MDL_key has standard layout
MY_LOCALE turns out to have standard layout as well
PFS_events_statements was trivially transformed to standard layout by moving the base class to a data member.
With a small test program you can easily experiment when offsetof is not allowed. https://godbolt.org offers convenient access to many compilers, including GCC 4.8.5, which is the oldest that we currently support.
#include <type_traits>
class B {
int m1;
public :
int m2= 1;
B(): m1(2) {}
bool eq() const { return m1==m2; }
static int o2() { return __builtin_offsetof(B, m2); }
};
int f()
{
return std::is_standard_layout<B>::value;
}
int g() { return B::o2(); }
Apart from Master_info , which is the antagonist in this bug, we have a number of data types on which my_offsetof() is being invoked and offsetof() cannot be invoked due to non-standard layout:
Table_triggers_list
TABLE_LIST
ACL_ROLE
ACL_USER_BASE
These classes either derive from a base class (similar to how PFS_events_statements did before my cleanup) or they encapsulate nonstandard-layout objects, such as List<String> .
Bug
Critical
MDEV-25454 Make MariaDB server UBSAN safe
Because my_offsetof() appears to exercise undefined pointer arithmetics, we’d better replace it with the standard macro offsetof() where possible:
With a small test program you can easily experiment when offsetof is not allowed. https://godbolt.org offers convenient access to many compilers, including GCC 4.8.5, which is the oldest that we currently support.
#include <type_traits>B(): m1(2) {}};{}Apart from Master_info, which is the antagonist in this bug, we have a number of data types on which my_offsetof() is being invoked and offsetof() cannot be invoked due to non-standard layout:
These classes either derive from a base class (similar to how PFS_events_statements did before my cleanup) or they encapsulate nonstandard-layout objects, such as List<String>.