Problem in building on CentOS 6.4 #6

ktk57 · 2014-05-23T11:58:40Z

I am trying to build https://github.com/facebook/mysql-5.6 on CentOS 6.4 and the build is failing(I am using devtools-2)

Scanning dependencies of target merge_large_tests-t
[ 82%] Building CXX object unittest/gunit/CMakeFiles/merge_large_tests-t.dir/merge_large_tests.cc.o
In file included from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:13:0:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc: In member function 'virtual void log_throttle_unittest::LogThrottleTest_SlowLogBasic_Test::TestBody()':
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc:84:78: error: invalid conversion from 'bool ()(THD, const char_, uint) {aka bool ()(THD, const char_, unsigned int)}' to 'bool ()(THD, const char_, uint, system_status_var_) {aka bool ()(THD, const char_, unsigned int, system_status_var_)}' [-fpermissive]
In file included from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/fake_table.h:19:0,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/mock_field_timestamp.h:19,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/copy_info-t.cc:22,
from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:2:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/sql/sql_class.h:1469:3: error: initializing argument 4 of 'Slow_log_throttle::Slow_log_throttle(ulong_, mysql_mutex_t_, ulong, bool ()(THD, const char_, uint, system_status_var_), const char_)' [-fpermissive]
In file included from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:13:0:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc: In member function 'virtual void log_throttle_unittest::LogThrottleTest_SlowLogThresholdChange_Test::TestBody()':
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc:122:78: error: invalid conversion from 'bool ()(THD, const char_, uint) {aka bool ()(THD, const char_, unsigned int)}' to 'bool ()(THD, const char_, uint, system_status_var_) {aka bool ()(THD, const char_, unsigned int, system_status_var_)}' [-fpermissive]
In file included from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/fake_table.h:19:0,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/mock_field_timestamp.h:19,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/copy_info-t.cc:22,
from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:2:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/sql/sql_class.h:1469:3: error: initializing argument 4 of 'Slow_log_throttle::Slow_log_throttle(ulong_, mysql_mutex_t_, ulong, bool ()(THD, const char_, uint, system_status_var_), const char_)' [-fpermissive]
In file included from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:13:0:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc: In member function 'virtual void log_throttle_unittest::LogThrottleTest_SlowLogSuppressCount_Test::TestBody()':
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/log_throttle-t.cc:154:78: error: invalid conversion from 'bool ()(THD, const char_, uint) {aka bool ()(THD, const char_, unsigned int)}' to 'bool ()(THD, const char_, uint, system_status_var_) {aka bool ()(THD, const char_, unsigned int, system_status_var_)}' [-fpermissive]
In file included from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/fake_table.h:19:0,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/mock_field_timestamp.h:19,
from /home/kartik/mysql-5.6-webscalesql-5.6.16-47/unittest/gunit/copy_info-t.cc:22,
from /home/kartik/build_facebook_mysql_5.6/unittest/gunit/merge_large_tests.cc:2:
/home/kartik/mysql-5.6-webscalesql-5.6.16-47/sql/sql_class.h:1469:3: error: initializing argument 4 of 'Slow_log_throttle::Slow_log_throttle(ulong_, mysql_mutex_t_, ulong, bool ()(THD, const char_, uint, system_status_var_), const char_)' [-fpermissive]
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-null-dereference" [enabled by default]
make[2]: *_* [unittest/gunit/CMakeFiles/merge_large_tests-t.dir/merge_large_tests.cc.o] Error 1
make[1]: *** [unittest/gunit/CMakeFiles/merge_large_tests-t.dir/all] Error 2
make: *** [all] Error 2

Am I missing something? Please let me know if there is a mailing list.
I basically need a non-blocking mysqlclient(C bindings).

Thanks for your patience !

steaphan-fb-com · 2014-10-14T19:03:25Z

I hope you've managed to resolve this in the meantime.

If not, I suggest you try to use the most recent branch, as the one used here is actually pretty old at this point. If that doesn't work, please open another issue with the details, and I will take a closer look.

Sorry for my delayed response on this one.

AllenChien · 2015-07-02T11:27:02Z

I encounter below compile errors, code base is cloned from latest github.

CentOS release 6.4 (Final)
gcc version 4.8.2 (GCC)

[ 63%] Building C object vio/CMakeFiles/vio.dir/viosslfactories.c.o
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c: In function ‘new_VioSSLFd’:
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:265:3: warning: implicit declaration of function ‘ERR_clear_error’ [-Wimplicit-function-declaration]
ERR_clear_error();
^
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:306:5: error: unknown type name ‘EC_KEY’
EC_KEY ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
^
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:306:5: warning: implicit declaration of function ‘EC_KEY_new_by_curve_name’ [-Wimplicit-function-declaration]
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:306:45: error: ‘NID_X9_62_prime256v1’ undeclared (first use in this function)
EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
^
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:306:45: note: each undeclared identifier is reported only once for each function it appears in
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:308:7: warning: implicit declaration of function ‘SSL_CTX_set_tmp_ecdh’ [-Wimplicit-function-declaration]
SSL_CTX_set_tmp_ecdh(ssl_fd->ssl_context, ecdh);
^
/data1/mysql/mysql-5.6-webscalesql-5.6.23.71/vio/viosslfactories.c:309:7: warning: implicit declaration of function ‘EC_KEY_free’ [-Wimplicit-function-declaration]
EC_KEY_free(ecdh);
^
make[2]: ** [vio/CMakeFiles/vio.dir/viosslfactories.c.o] Error 1
make[1]: *** [vio/CMakeFiles/vio.dir/all] Error 2
make: *** [all] Error 2

AllenChien · 2015-07-03T02:40:22Z

cmake with -DWITH_SSL=system, everything goes fine!

Summary: I saw this intermittent ASAN failure ==662590== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000098 (pc 0x00000112fc64 sp 0x7f0324c71710 bp 0x7f0324c71760 T21) AddressSanitizer can not provide additional info. #0 0x112fc63 in my_pthread_fastmutex_lock /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/mysys/thr_mutex.c:479 #1 0x18fb4b0 in _ZN23Dropped_indices_manager14remove_indicesERKSt13unordered_setIjSt4hashIjESt8equal_toIjESaIjEEP12Dict_manager /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/include/mysql/psi/mysql_thread.h:688 #2 0x18b031a in _Z17drop_index_threadPv /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/storage/rocksdb/ha_rocksdb.cc:4927 #3 0x7f0337d611e8 in _ZN6__asan10AsanThread11ThreadStartEv ??:0 #4 0x7f03376dbfa7 in start_thread ??:0 #5 0x7f0335a5f5bc in __clone ??:0 Thread T21 created by T0 here: #0 0x7f0337d5121b in pthread_create ??:0 #1 0x18aec6a in _ZL17rocksdb_init_funcPv /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/storage/rocksdb/ha_rocksdb.cc:1765 #2 0x60a039 in _Z24ha_initialize_handlertonP13st_plugin_int /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/sql/handler.cc:673 #3 0xab04e0 in _ZL17plugin_initializeP13st_plugin_int /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/sql/sql_plugin.cc:1137 #4 0xac8fe3 in _Z11plugin_initPiPPci /data/users/jenkins/workspace/myrocks-prod/BUILD_TYPE/ASan/CLIENT_MODE/Sync/PAGE_SIZE/32/TEST_SET/MixedOther/label/mysql/mysql/sql/sql_plugin.cc:1431 #5 0x5ef74c in _ZL22init_server_componentsv .cc:5482 #6 0x5f0cce in _Z11mysqld_mainiPPc .cc:6254 #7 0x7f033597defe in __libc_start_main ??:0 #8 0x5d86a8 in _start /home/engshare/third-party2/glibc/2.17/src/glibc-2.17/csu/../sysdeps/x86_64/start.S:123 ==662590== ABORTING It looks like the Dropped_indices_manager mutex is accessed by the thread after the mutex was cleaned up. I'm moving the cleanup of the manager to the thread in hopes that this will fix the failure. Test Plan: ran rocksdb suite, nothing failed Reviewers: hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D42909

Summary: Fix yet another memory leak reported by ASAN, in perfschema dynamic array of instrument config. LeakSanitizer reported: ==1556117==ERROR: LeakSanitizer: detected memory leaks Direct leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7fd5cee05151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) #1 0x120ea19 in my_malloc /home/tianx/mysql/5.6/mysys/my_malloc.c:38 #2 0x1891606 in add_pfs_instr_to_array(char const*, char const*) /home/tianx/mysql/5.6/storage/perfschema/pfs_server.cc:251 #3 0x76bd26 in mysqld_get_one_option /home/tianx/mysql/5.6/sql/mysqld.cc:11033 #4 0x1242157 in my_handle_options /home/tianx/mysql/5.6/mysys_ssl/my_getopt.cc:659 #5 0x77d88e in handle_early_options(char) /home/tianx/mysql/5.6/sql/mysqld.cc:8750 #6 0x78d003 in mysqld_main(int, char**) /home/tianx/mysql/5.6/sql/mysqld.cc:6936 #7 0x7fd5cc942857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) #8 0x764398 in _start (/data/users/tianx/mysql/5.6/_build-5.6-ASan-PerfSchema/sql/mysqld+0x764398) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). Reviewed By: gunnarku Differential Revision: D5210977 fbshipit-source-id: 54e7744

Summary: When `use-threads` (worker threads) param is larger than 0, the code branch didn't close mysql initialized in the main thread. ASAN reports the following leak: ==228195==ERROR: LeakSanitizer: detected memory leaks Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0x7f5869304151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) #1 0x45ef69 in my_malloc /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/mysys/my_malloc.c:38 #2 0x415a8f in mysql_init /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/sql-common/client.c:2613 #3 0x406049 in do_init /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/client/mysqlimport.c:426 #4 0x406049 in main /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/client/mysqlimport.c:654 #5 0x7f586727a857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) #6 0x406cb8 in _start (/data/sandcastle/boxes/trunk-git-mysql-int-secondary/_build-5.6-ASan-PerfSchema/client/mysqlimport+0x406cb8) This diff fixes it. Reviewed By: gunnarku Differential Revision: D5235584 fbshipit-source-id: 5ffa8eb

Summary: Fix the following leak reported by ASAN: ==2475771==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f97e37fb151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) #1 0x445229 in my_malloc /home/tianx/mysql/5.6/mysys/my_malloc.c:38 #2 0x44b908 in _lf_alloc_new /home/tianx/mysql/5.6/mysys/lf_alloc-pin.c:440 #3 0x44dfd0 in lf_hash_insert /home/tianx/mysql/5.6/mysys/lf_hash.c:390 #4 0x416220 in find_or_create_file(PFS_thread*, PFS_file_class*, char const*, unsigned int, bool) /home/tianx/mysql/5.6/storage/perfschema/pfs_instr.cc:1353 #5 0x439265 in create_file_v1 /home/tianx/mysql/5.6/storage/perfschema/pfs.cc:1791 #6 0x4099f6 in test_locker_disabled() /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1150 #7 0x40aef7 in do_all_tests() /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1659 #8 0x403d38 in main /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1668 #9 0x7f97e2288857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) #10 0x404bf8 in _start (/data/users/tianx/mysql/5.6/_build-5.6-ASan-PerfSchema/storage/perfschema/unittest/pfs-t+0x404bf8) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s). It seems the instrumented file's name is normalized to contain `-instrumented` in it. Previously test wasn't able to clean up the instrumented file "foo". Depends on D5235521 Reviewed By: gunnarku Differential Revision: D5235559 fbshipit-source-id: 8493330

Summary: Fix yet another memory leak reported by ASAN, in perfschema dynamic array of instrument config. LeakSanitizer reported: ==1556117==ERROR: LeakSanitizer: detected memory leaks Direct leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7fd5cee05151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) facebook#1 0x120ea19 in my_malloc /home/tianx/mysql/5.6/mysys/my_malloc.c:38 facebook#2 0x1891606 in add_pfs_instr_to_array(char const*, char const*) /home/tianx/mysql/5.6/storage/perfschema/pfs_server.cc:251 facebook#3 0x76bd26 in mysqld_get_one_option /home/tianx/mysql/5.6/sql/mysqld.cc:11033 facebook#4 0x1242157 in my_handle_options /home/tianx/mysql/5.6/mysys_ssl/my_getopt.cc:659 facebook#5 0x77d88e in handle_early_options(char) /home/tianx/mysql/5.6/sql/mysqld.cc:8750 facebook#6 0x78d003 in mysqld_main(int, char**) /home/tianx/mysql/5.6/sql/mysqld.cc:6936 facebook#7 0x7fd5cc942857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) facebook#8 0x764398 in _start (/data/users/tianx/mysql/5.6/_build-5.6-ASan-PerfSchema/sql/mysqld+0x764398) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). Test Plan: mtr and the following test: mysqltest.sh --testset=ParallelBig --perfschema --asan --workers=16 auth_sec.secure_file_priv_error Reviewers: gunnarku Reviewed By: gunnarku Subscribers: webscalesql-eng@fb.com Differential Revision: https://phabricator.intern.facebook.com/D5210977 Tasks: 17217920 Signature: t1:5210977:1497296884:606f6587bfe1595abd7188c1a27f57805b11ee96

Summary: When `use-threads` (worker threads) param is larger than 0, the code branch didn't close mysql initialized in the main thread. ASAN reports the following leak: ==228195==ERROR: LeakSanitizer: detected memory leaks Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0x7f5869304151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) facebook#1 0x45ef69 in my_malloc /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/mysys/my_malloc.c:38 facebook#2 0x415a8f in mysql_init /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/sql-common/client.c:2613 facebook#3 0x406049 in do_init /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/client/mysqlimport.c:426 facebook#4 0x406049 in main /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/client/mysqlimport.c:654 facebook#5 0x7f586727a857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) facebook#6 0x406cb8 in _start (/data/sandcastle/boxes/trunk-git-mysql-int-secondary/_build-5.6-ASan-PerfSchema/client/mysqlimport+0x406cb8) This diff fixes it. Test Plan: mtr mysqltest.sh --asan main.mysqldump Reviewers: gunnarku Reviewed By: gunnarku Subscribers: webscalesql-eng@fb.com Differential Revision: https://phabricator.intern.facebook.com/D5235584 Tasks: 17217920 Signature: t1:5235584:1497365780:20cf2d394452bc0dbef4645dce8a60df038f8969

Summary: Fix the following leak reported by ASAN: ==2475771==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f97e37fb151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) facebook#1 0x445229 in my_malloc /home/tianx/mysql/5.6/mysys/my_malloc.c:38 facebook#2 0x44b908 in _lf_alloc_new /home/tianx/mysql/5.6/mysys/lf_alloc-pin.c:440 facebook#3 0x44dfd0 in lf_hash_insert /home/tianx/mysql/5.6/mysys/lf_hash.c:390 facebook#4 0x416220 in find_or_create_file(PFS_thread*, PFS_file_class*, char const*, unsigned int, bool) /home/tianx/mysql/5.6/storage/perfschema/pfs_instr.cc:1353 facebook#5 0x439265 in create_file_v1 /home/tianx/mysql/5.6/storage/perfschema/pfs.cc:1791 facebook#6 0x4099f6 in test_locker_disabled() /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1150 facebook#7 0x40aef7 in do_all_tests() /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1659 facebook#8 0x403d38 in main /home/tianx/mysql/5.6/storage/perfschema/unittest/pfs-t.cc:1668 facebook#9 0x7f97e2288857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) facebook#10 0x404bf8 in _start (/data/users/tianx/mysql/5.6/_build-5.6-ASan-PerfSchema/storage/perfschema/unittest/pfs-t+0x404bf8) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s). It seems the instrumented file's name is normalized to contain `-instrumented` in it. Previously test wasn't able to clean up the instrumented file "foo". Depends on D5235521 Test Plan: mtr mysqltest.sh --asan --perfschema --unit-tests --unit-tests-report empty_table Reviewers: gunnarku Reviewed By: gunnarku Subscribers: webscalesql-eng@fb.com Differential Revision: https://phabricator.intern.facebook.com/D5235559 Tasks: 17217920 Signature: t1:5235559:1497365801:a1b886d1f09005cd17196dfa44837e4336a5dfe5

Summary: As title. Test Plan: I couldn't reproduce it on my local server, but it fails consistently on sandcastle. Sandcastle filename+dirname may be too long and cause flakiness, while the `-instrumented` postfix has some magic of avoiding/cleaning up leaks. Ran `[build dir]/storage/perfschema/unittest/pfs-t`. Before the fix: ================================================================= ==678962==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7fd33820a151 in __interceptor_calloc (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libasan.so.2+0x9a151) facebook#1 0x447409 in my_malloc /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/mysys/my_malloc.c:38 facebook#2 0x44dae8 in _lf_alloc_new /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/mysys/lf_alloc-pin.c:440 facebook#3 0x4501b0 in lf_hash_insert /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/mysys/lf_hash.c:390 facebook#4 0x418400 in find_or_create_file(PFS_thread*, PFS_file_class*, char const*, unsigned int, bool) /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/storage/perfschema/pfs_instr.cc:1353 facebook#5 0x441926 in end_file_open_wait_and_bind_to_descriptor_v1 /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/storage/perfschema/pfs.cc:3996 facebook#6 0x40c160 in test_file_instrumentation_leak() /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/storage/perfschema/unittest/pfs-t.cc:1438 facebook#7 0x40d0dc in do_all_tests() /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/storage/perfschema/unittest/pfs-t.cc:1659 facebook#8 0x403d38 in main /data/sandcastle/boxes/trunk-git-mysql-int-tools-primary/mysql-src/storage/perfschema/unittest/pfs-t.cc:1667 facebook#9 0x7fd336c97857 in __libc_start_main (/usr/local/fbcode/gcc-5-glibc-2.23/lib/libc.so.6+0x20857) facebook#10 0x404bf8 in _start (/data/sandcastle/boxes/trunk-git-mysql-int-secondary/_build-5.6-ASan-PerfSchema/storage/perfschema/unittest/pfs-t+0x404bf8) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s). Clean run after the change. Reviewers: gunnarku Reviewed By: gunnarku Differential Revision: https://phabricator.intern.facebook.com/D5243042 Tasks: 17217920 Signature: t1:5243042:1497460215:c79e007405676c8ea585e1eb09c881fd3ed1ce1f

Summary: 1. Disable rpl_skip_tx_api and read_free_rpl related tests 2. Add analyze table t to force information_schema update 3. Add missing MYSQL_SST_DUMP environment variable. Reviewed By: lloyd Differential Revision: D17622876

Summary: In MySQL 8.0.17, sending data stage is gone. As a result, in testcase #5/#6 the test is waiting on sending data stage and timed out, and at that point the lock is already taken, so trying to take the same lock on the same row on another connection simply timed out, instead of getting a deadlock/snapshot conflict. For now I'm using an slightly earlier stage "executing" - this aligns what Percona has done and we can see if this works reasonably well. If not we can see if we can introduce the old stage back. Note: The current implementation of the test can be flaky - it depends on the SELECT has already started the scan over some of the rows and taken snapshot, but before taking the lock, so that you can get snapshot conflict in another connection doing delete over the same row (instead of timeout with lock contention). Given that the test is intended to test taking snapshot before doing any get, this is fortunately the best the test can do at this point. Reviewed By: lloyd Differential Revision: D18716622

… enabled Summary: For secondaries, when enable_super_log_bin_read_only is on and read_only is on, currently it will forbid to install/uninstall plugin during run time. install/uninstall plugin doesn't generate event in binlog, although the thread thd contains OPTION_BIN_LOG flag due to log_slave_updates is on by default in secondaries. It should be safe to execute install/uninstall plugin. the change is to call set_skip_readonly_check() before install/uninstall plugin and call reset_skip_readonly_check()(for completeness) after install/uninstall plugin. BTW, mysql will always call reset_skip_readonly_check() for at the beginning of each statement. thus set_skip_readonly_check() won't affect other statement. ``` #0 THD::reset_skip_readonly_check (this=0x7fb5c1a0b000) at /home/luqun/mysql/mysql-8.0.20/sql/sql_class.h:1754 #1 0x0000000005a500e1 in THD::reset_for_next_command (this=0x7fb5c1a0b000) at /home/luqun/mysql/mysql-8.0.20/sql/sql_parse.cc:5892 #2 0x0000000005a517a5 in mysql_reset_thd_for_next_command (thd=0x7fb5c1a0b000) at /home/luqun/mysql/mysql-8.0.20/sql/sql_parse.cc:5817 #3 0x0000000005a50466 in mysql_parse (thd=0x7fb5c1a0b000, parser_state=0x7fb5f6bb4560, last_timer=0x7fb5f6bb39b0) at /home/luqun/mysql/mysql-8.0.20/sql/sql_parse.cc:6056 #4 0x0000000005a4c7c9 in dispatch_command (thd=0x7fb5c1a0b000, com_data=0x7fb5f6bb4d98, command=COM_QUERY) at /home/luqun/mysql/mysql-8.0.20/sql/sql_parse.cc:2222 #5 0x0000000005a4f991 in do_command (thd=0x7fb5c1a0b000) at /home/luqun/mysql/mysql-8.0.20/sql/sql_parse.cc:1556 #6 0x0000000005ccd4f1 in handle_connection (arg=0x7fb5cc85b740) at /home/luqun/mysql/mysql-8.0.20/sql/conn_handler/connection_handler_per_thread.cc:330 #7 0x00000000078eb95b in pfs_spawn_thread (arg=0x7fb5f8c89720) at /home/luqun/mysql/mysql-8.0.20/storage/perfschema/pfs.cc:2884 #8 0x00007fb5f957020c in start_thread (arg=0x7fb5f6bb6700) at pthread_create.c:479 #9 0x00007fb5f971881f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ``` Reviewed By: george-reynya Differential Revision: D27213990

recover raft logs by removing partial trxs Summary: Port D24628821 mysqld removes partial trxs in the tail of trx log (named binary-logs on primaries and apply-logs on secondaries) during startup. However, relay logs were not of much importance since it was anyways discarded and a new one would be created. However, with raft, this is not ideal. Relay logs are raft logs on secondaries and have to be kept around (and kept sane and consistent). This diff adds the ability to remove partial trxs from raft/relay logs. Much of the code to open the last relay log (based on relay log index) and identify partial trxs is borrowed from existing logic in MYSQL_BIN_LOG::open_binlog() and binlog_recover() Reviewed By: Pushapgl Differential Revision: D26447448 --------------------------------------------------------------------- Checking for inited bool to make sure global_init_info was successful Summary: Port D25584004 A master.info and relay.info file can be present but needs to be properly inited for use. We were bypassing the inited check which could lead to issues in Raft. In case there is an error in global_init_info, Raft will do a raft_reset_slave and make another attempt at it. If both recourses fail, the init of the plugin would fail. Reviewed By: Pushapgl Differential Revision: D26447457 --------------------------------------------------------------------- Support for dumping raft logs to vanilla async replicas Summary: [Porting Notes] We want to dump raft logs to vanilla async replicas regardless of whether it's the relay log or binlog. Effectively after this change we'll dump relay logs on the followers and binlogs on the leader. When the raft role changes, the logs to the dumped are also changed. Dump_log class is introduced as a thin wrapper/continer around mysql_bin_log or rli->relay_log and is inited with mysql_bin_log to emulate vanilla mysql behavior. Dump threads use the global dump_log object instead of mysql_bin_log directly. We switch the log in dump log only when raft role changes (in binlog_change_to_binlog() and binlog_change_to_apply_log()). During raft role change we take all log releated locks (LOCK_log, LOCK_index, LOCK_binlog_end_pos, and dump log lock) to serialize it with other log operations like dumping logs. Related doc - https://fb.quip.com/oTVAAdgEi4zY This diff contains below 7 patches: D23013977 D24766787 D24716539 D24900223 D24955284 D25174166 D25775525 Reviewed By: luqun Differential Revision: D26141496 --------------------------------------------------------------------- Fixed the flaky raft test suite Summary: First clean run of entire raft test suite :) **Changes** * Reset apply_logs on raft secondaries before the start of every test * Increased the lock timeouts and changed isolation level in rpl_raft_slave_out_of_order_commit. Reviewed By: luqun Differential Revision: D26651257 --------------------------------------------------------------------- return error from Raft_replication_delegate when plugin is not available Summary: Port D23065441 (b9067f7) The new macro is used to call into raft plugin. If plugin gets unloaded accidentally when enable_raft_plugin is ON, then this STRICT version returns failure. This is to be called only by raft plugin currently Reviewed By: Pushapgl Differential Revision: D26447523 --------------------------------------------------------------------- Adding timestamps for raft rotates which happen in the context of listener thread Summary: Port D25572614 The timestamp of a binlog event is picked up from the when field in the event. In most cases of rotation, the when is left unpopulated during rotation for the top 3 events (fd, pgtid, metadata). However in such a situation, a normal rotate (flush binary logs) still manages to get a valid timestamp, since the thread in which the flush binary logs happens has a valid start time. Now enter Raft relay log rotations. In those cases and in the case of config change rotate, the rotations are happening in the context of a raft listener queue thread. In that context, the when and start time of the thread are both 0. The diff handles this case by populating the when field appropriately. Reviewed By: bhatvinay Differential Revision: D26194612 --------------------------------------------------------------------- Raft abrupt stepdown and trim binlog file / gtid test Summary: binlog file should get trimmed for abrupt stepdown Reviewed By: Pushapgl, bhatvinay Differential Revision: D26169975 --------------------------------------------------------------------- Port: Fixes around raft log truncation. Summary: **Notes** * New functions to block and unblock dump threads for plugin to use during raft log truncation. Below check is already done in raft plugin as part of raft plugin in D26866429. * Re-init rli->cur_log in Relay_log_info::rli_init_info() instead of just seeking to the beginning to handle the case when raft log is truncated before starting the applier Reviewed By: luqun Differential Revision: D26759813 --------------------------------------------------------------------- rebase due to relay log Format_description_event event size difference Summary: WL#3549: Binlog Compression add extra 1 bytes data into Format_description_event 3298 @@ -134,6 +137,7 @@ Format_description_event::Format_description_event(uint8_t binlog_ver, 3299 VIEW_CHANGE_HEADER_LEN, 3300 XA_PREPARE_HEADER_LEN, 3301 ROWS_HEADER_LEN_V2, 3302 + TRANSACTION_PAYLOAD_EVENT, 3303 }; Reviewed By: Pushapgl Differential Revision: D27145095 --------------------------------------------------------------------- fix raft change string metadata event Summary: Saw a bunch stage-1 replicaset instance failed due to config change string failure during add/remove instance ``` I0401 00:16:10.894434 1823842 IoCacheUtils.cpp:333] getConfigChangeString eventType = ^G E0401 00:16:10.894451 1823842 IoCacheUtils.cpp:363] Failed to read metadata event body from cache E0401 00:16:10.894456 1823842 MysqlRaft.cpp:659] [replicate] Failed to get config change string from iocache 2021-04-01T00:16:10.894464-07:00 8307 [ERROR] [MY-010207] [Repl] Run function 'before_flush' in plugin 'RPL_RAFT' failed 2021-04-01T00:16:10.894478-07:00 8307 [ERROR] [MY-000000] [Server] Failed to rotate binary log ``` After some investigation, the issue is caused is that calculate metadata event length with config change string but forgot write config change string into event body. Reviewed By: Pushapgl Differential Revision: D27504157 --------------------------------------------------------------------- Tells raft mode in binlog Summary: WIn-Win: Tell whether this binlog is generated while this host is in raft mode. We already has the bit in FD event, and this diff just speaks it out. Reviewed By: mpercy Differential Revision: D28664300 --------------------------------------------------------------------- fix flaky raft testcase Summary: There are multiple issues for MTR: 1. in sql/rpl_binlog_sender.cc, if secondaries IO thread receives fatal_error, it will quit IO thread instead of reconnect. use unknown error so that secondary IO thread can try to reconnect 2. mtr.add_suppression() call: mtr.add_suppression() will execute an insert mysql statement into mtr.test_suppressions table and mtr.test_suppressions table doesn't contain primary key, thus during idempotent recovery, secondary will fail to execute mtr.add_suppression() due to missing PK. Try to move all mtr.add_suppression() at the end of testcase to workaround idempotent recovery failure. 3. When promotion, use raft_promote_to_leader.inc instead of `set rpl_raft_new_leader_uuid`, since raft_promote_to_leader will wait the new primary state becomes writeable 4. pass specific warning instead of '.*' to mtr.add_supression 5. etc Reviewed By: Pushapgl, bhatvinay Differential Revision: D28774820 --------------------------------------------------------------------- Using locks in Dump_log methods only when raft is enabled Summary: We don't need to take locks in non-raft mode since the underlying MYSQL_BIN_LOG obj will never change. To handle race between updation of enable_raft_plugin var and using its values in Dump_log we kill and block all dump threads while updating the var and unblock them once the var is updated. Reviewed By: bhatvinay Differential Revision: D28905522 --------------------------------------------------------------------- leader election to be a sync point in the new leader Summary: Port of D27582002 (39c70ca) from 5.6.35 to 8.0 Newly elected raft leader makes sure that all trxs from the previous leader is committed by sql appliers. It then switches the server's trx logs from apply-log-* to binary-log-*. To other part of the system this looks like a rotation, but the necessary sync calls are not made here. So, if the server (or os) restarts, then the storage engine could lose the commit markers of the last batch of trxs. This will result in silent data drift. This diff fixes the problem by making an explicit call to ha_flush_logs() before switching the server's trx logs Reviewed By: luqun Differential Revision: D28880407 --------------------------------------------------------------------- Error out SQL thread on out of order opids in raft logs Summary: OpIds should always be in order in the raft logs. Added a check in SQL threads that thows an error and stops the applier when out of order opids are detected. Reviewed By: li-chi Differential Revision: D28810840 --------------------------------------------------------------------- add GET_COMMITTED_GTIDS for raft Summary: During recovery Raft Log::Init needs to check with server what gtids have been committed. Before doing that it finds the entire set of trxs in the last raft log. The difference between logged - committed are the pending opids. Reviewed By: Pushapgl Differential Revision: D29622786 --------------------------------------------------------------------- raft: skip mts_recovery_groups during start slave Summary: During MySQL8+Raft DMP, some instance fail to switch to Leader or start slave ``` 2021-06-24T17:56:38.627423-07:00 431 [Note] [MY-010574] [Repl] Slave: MTS group recovery relay log info group_master_log_name /data/mysql/3127/bls-unittestdb658.frc2-3305-mysql.replicaset.180021/binary-logs-3727.000033, event_master_log_pos 1129. 2021-06-24T17:56:38.627473-07:00 431 [ERROR] [MY-010575] [Repl] Error looking for file after /binlogs/binary-logs-3307.000120. 2021-06-24T17:56:38.627516-07:00 431 [ERROR] [MY-000000] [Repl] load_mi_and_rli_from_repositories: rli_init_info returned error ``` similar to 5.6, we don't need to run mts_recovery_groups due to GTID_MODE is always enabled. Reviewed By: Pushapgl Differential Revision: D29520066 --------------------------------------------------------------------- update RaftListenerCallbackArg struct Summary: Due to contract between raft plugin and mysql change, update RaftListenerCallbackArg struct to add master_uuid field Reviewed By: Pushapgl, bhatvinay Differential Revision: D29981349 --------------------------------------------------------------------- always check mi during raft_reset_slave Summary: add similar nullptr check for raft_reset_slave as raft_stop_sql_thread Reviewed By: bhatvinay Differential Revision: D29967915 --------------------------------------------------------------------- raft mtr: update rpl_end_raft.inc for disable-raft Summary: rpl_end_raft.inc will unregister raft plugin which will call reset slaves when online disable-raft is enabled. move rpl_end_raft.inc after rpl_stop_slaves.inc to stop slave correctly first. after stop slaves, call mtr.add_suppression("") won't replicate to slaves. just call mtr.add_suppression("") for all instances(replicas). Reviewed By: yizhang82 Differential Revision: D30062236 --------------------------------------------------------------------- fix master_uuid Summary: fix master_uuid in raft mode. Reviewed By: luqun Differential Revision: D30261465 --------------------------------------------------------------------- incorrect File_size value in show raft logs result Summary: in show raft logs result, the File_size for latest logs file isn't updated correctly. such as show raft logs; ``` +-------------------------+------------ | Log_name | File_size | | binary-logs-3304.000670 | 1529 | ``` in fact ``` -rw-r----- 1 mysql backup 1669180487 Aug 4 14:49 binary-logs-3304.000670 -rw-r----- 1 mysql backup 1723994154 Aug 4 14:49 binary-logs-3304.000670 ``` the file_size from show raft logs is always 1529 but the real file_size is 1669180487. The issue is related when writing IO_CACHE directly, its wrapper ostream's position isn't updated. Reviewed By: yizhang82 Differential Revision: D30116345 --------------------------------------------------------------------- Add gtid_purged_for_tailing Summary: Add a new global variable gtid_purged_for_tailing. It shows the purged GTID for binlog in non-raft mode, and purged GTID for raft log in raft mode. Reviewed By: abhinav04sharma Differential Revision: D29372776 --------------------------------------------------------------------- disable skip_setup_replica_if_unnecessary Summary: After sync with latest official raft plugin, most of MTR failed due to skip_setup_replica_if_unnecessary optimize. Reviewed By: yizhang82 Differential Revision: D30821648 --------------------------------------------------------------------- latency histograms for raft trx wait Summary: Port of support added for the same in mysql 5.6. Should help monitor latencies in 8.0 + raft stage -1 replicasets. Reviewed By: luqun Differential Revision: D31064764 --------------------------------------------------------------------- handle cases where clean shutdown in raft aborts trxs Summary: This is a port of the feature in 5.6. Reviewed By: anirbanr-fb Differential Revision: D31070593 --------------------------------------------------------------------- fix crash during binlog purging Summary: Any error returned by the plugin during binlog purging results in a crash in mysql8 as the server tries to execute binlog_error_action_abort. We need to differentiate explicitly between a plugin error and other error (such as error related to doing disk IO etc). In thsi particular case, the crash is because of trying to purge a file that does not exist (i.e which is already purged previosuly) and raft cannot find it in its index chunk (so it returns a error). Reviewed By: anirbanr-fb Differential Revision: D31149997 --------------------------------------------------------------------- update flaky rpl_raft_purged_gtids_dump_threads Summary: rpl_raft_purged_gtids_dump_threads MTR failed due to "Cannot replicate because the master purged required binary logs" after server4 will tail server2. Try to sync server4 before switch to tail server2. Reviewed By: bhatvinay Differential Revision: D30818078 --------------------------------------------------------------------- fix various porting issues in mysql8 (raft) crash recovery Summary: 1. Trimming of the binlog is left to raft plugin (based on the current leader's log). Server should skip this step as part of recovery. This essentially means setting 'valid_pos' to the last successfully parsed trx in the trx log (instead of the engine's view of the trx log) in MYSQL_BIN_LOG::recover() 2. executed_gtid_set should be initialized based on the engine's view of the trx log file cordinates. So, during startup appropriate flags need to be passed into MYSQL_BIN_LOG::init_gtid_sets(). init_gtid_sets() is already changed to handle this, but the flag was not set correctly during server startup 3. Another fix is in MYSQL_BIN_LOG::init_gtid_sets()to corretly set the position to read and calculate executed-gtid-set (based on the file name read from the engine) Reviewed By: anirbanr-fb Differential Revision: D31284902 --------------------------------------------------------------------- show_raft_status should take LOCK_status Summary: This is a straight port of a 5.6 patch to 8.0 SHOW RAFT STATUS and SHOW GLOBAL STATUS go to the same functions in the plugin and access shared data structures. These functions return internal char * pointers to plugin global variables. They need to be serialized with LOCK_status otherwise it leads to race conditions. Reviewed By: li-chi Differential Revision: D31318340 --------------------------------------------------------------------- Disallowing reset master on raft replicasets Summary: This is a straight port of similar patch on 5.6 raft reset master is inherently not raft compliant. Its get rid of all binlogs and make an instance appear like a fresh single instance database without consulting the ring. We need to block it. However under certain circumstances (in the future ) e.g. during first time replicaset build, or when we can guarantee that instance is single node raft ring, we can potentially do a reset master followed by rebootstrap of raft. This can also be achieved by disabling raft, reset master and then re-enabling raft, however to keep open the door, I have left a force option and will thread a mechanism from the plugin to call reset_master(force=true) Reviewed By: li-chi Differential Revision: D31299214 --------------------------------------------------------------------- Setting topology config in MTR Summary: Setting topology config in MTR so that feature that use topology config can be tested easily. Setting rpl_raft_skip_smc_updates to avoid unnecessary calls to SMC (even though we supply a dummy replicaset name). Reviewed By: li-chi Differential Revision: D31543877 --------------------------------------------------------------------- Do not allow sql thread start when raft is doing a stop->{}->start transition Summary: This is a port of an existing patch made to 5.6 for Raft. Raft will do a stop of the SQL thread during StopAllWrites. Then it will repoint the binlog files and during that action, the SQL threads have to remain stopped. We block it out in this diff by keeping an atomic bool which can be checked from other functions. This only applies to raft mode i.e. enable_raft_plugin = true. Reviewed By: li-chi Differential Revision: D31319499 --------------------------------------------------------------------- Handle printing of FD event generated by slave SQL thread Summary: Early returning in the FD:print() function makes mysqlbinlog not be able to parse Raft logs on secondaries. The original commit which added this is d048c0f (P173872135) To comply with the intent of the original bug fix, we avoid printing the FD event of a relay log as a 'BINLOG'. Reviewed By: anirbanr-fb Differential Revision: D26359417 --------------------------------------------------------------------- Add exponential backoff for smart restart Summary: RAFT Instance crash and Tx Logs filling up. rocksdb can fill up txlogs. we should stop restarting mysqld if we have restarted many times in a day Reviewed By: anirbanr-fb Differential Revision: D27372750 --------------------------------------------------------------------- always release data_lock mutex to avoid deadlock Summary: in stage-1 replicaset, when kill a secondary instance, sometime the instance will run into deadlock due to process_raft_queue thread forgot to release its acquired mutex in raft_change_master Reviewed By: Pushapgl, bhatvinay Differential Revision: D27602667 --------------------------------------------------------------------- Gracefully exit mysqld_safe loop during backoff Summary: Currentt systemctl stop mysqld@3306.service can take 10 mins when mysqld_safe is in backoff period. D28517599 adds a interrupt to sleep in mysql_stop, and mysqld_safe immediately break the retry loop if sleep is interruptted. Reviewed By: anirbanr-fb Differential Revision: D28606439 --------------------------------------------------------------------- Fix heap overflow in group_relay_log_name handling Summary: We were accessing group_relay_log_name in Query_log_event::do_apply_event_worker() but it's assigned only after the coordinator thread encounters an end event (i.e. xid event or a query event with "COMMIT" or "ROLLBACK" query). This was causing a race between accessing group_relay_log_name in the worker thread and writing it on the coordinator thread. We don't need to set transaction position in events other than end event, so now we set transaction position in query event only if it's an end event. The race is eliminated because group_relay_log_name is set before enqueuing the event to the worker thread (in both dep repl and vanilla mts). Reviewed By: lth Differential Revision: D28767430 --------------------------------------------------------------------- fix memory during MYSQL_BIN_LOG::open_existing_binlog Summary: asandebug complain there are memory leaks during MYSQL_BIN_LOG open Direct leak of 50 byte(s) in 1 object(s) allocated from: #0 0x67460ef in malloc #1 0x93f0777 in my_raw_malloc(unsigned long, int) #2 0x93f064a in my_malloc(unsigned int, unsigned long, int) #3 0x93f0eb0 in my_strdup(unsigned int, char const*, int) #4 0x8af01a6 in MYSQL_BIN_LOG::open(unsigned int, char const*, char const*, unsigned int) #5 0x8af8064 in MYSQL_BIN_LOG::open_binlog(char const*, char const*, unsigned long, bool, bool, bool, Format_description_log_event*, unsigned int, RaftRotateInfo*, bool) #6 0x8b00c00 in MYSQL_BIN_LOG::new_file_impl(bool, Format_description_log_event*, RaftRotateInfo*) #7 0x8d65e47 in rotate_relay_log(Master_info*, bool, bool, bool, RaftRotateInfo*) #8 0x8d661c0 in rotate_relay_log_for_raft(RaftRotateInfo*) #9 0x8c7696a in process_raft_queue #10 0xa0fa1fd in pfs_spawn_thread(void*) #11 0x7f8c9a12b20b in start_thread release these memory before assign them Reviewed By: Pushapgl Differential Revision: D28819752 --------------------------------------------------------------------- Reduce max backoff time from 24h to 30mins Summary: Over the recent SEV0, raft instances crash looping because of block skew. Even after the clock is normal, mysqld_safe failed to bring back mysqld because extended 24hours backoff. This diff reduces the max backoff time from 24h to 30mins. So it will still keep trying, but not so aggressively that filling up the trx logs. Reviewed By: bart2 Differential Revision: D31661172 --------------------------------------------------------------------- Fix dump thread gtid_purged calculation in raft mode Summary: In raft mode, it is supposed to use gtid_purged_for_tailing, and lost_gtids should point to the it. Because of a bug, lost_gtids pointer's reference never changes, and always points to gtid_state->get_lost_gtids(), which is gtid_purged, not gtid_purged_for_tailing. Reviewed By: anirbanr-fb Differential Revision: D34110214 --------------------------------------------------------------------- Use last_master_timestamp from mysql_bin_log and not raft log Summary: last_master_timestamp in rli->relay_log is not initialized and not kept up to date. Although this sounds unintuitive from raft point of view, its not from the non-raft standpoint. In non-raft mode tailers are always served from binlog files and not from relay log files and hence keeping mysql_bin_log up to date was understandable. During the port of Dump log functionality to 8.0, I think by mistake references to mysql_bin_log in rpl_binlog_sender were migrated to Dump_log. This however caused a Uninitialized Memory Read issue because of the uninitialized last_master_timestamp value. Reviewed By: abhinav04sharma Differential Revision: D34843214 --------------------------------------------------------------------- Remove enable raft gating for block dump threads Summary: Partial revert of D28774820. This gate seems to be added after a minor comment during review. However, `block_dump_threads`, is set during the check phase for `enable_raft_plugin`. By gating the blocking on `enable_raft_plugin`, we pretty much make sure it'll never work. `block_dump_threads` is only set in https://fburl.com/code/ksk6v3yc, and that function is only called in Raft Listener + enable raft. I think removing the gate should be free of side effects, but another pair of eyes would be appreciated. Reviewed By: abhinav04sharma Differential Revision: D35200233

Summary: This fixes this leak: ``` Direct leak of 74 byte(s) in 2 object(s) allocated from: #0 0x9f235f in malloc #1 0xd88f47 in my_raw_malloc(unsigned long, int) #2 0xd88e1e in my_malloc(unsigned int, unsigned long, int) #3 0xc183e4 in read_ok_ex #4 0xc479d5 in authsm_handle_second_authenticate_user(mysql_async_auth*) #5 0xc32a97 in run_plugin_auth_nonblocking(MYSQL*, char*, unsigned int, char const*, char const*, char const*, char const*, bool) #6 0xc3329a in run_plugin_auth_nonblocking_wrapper #7 0xbfd0de in mysql_change_user_nonblocking #8 0xb7f162 in async_mysql_change_user_wrapper(MYSQL*, char const*, char const*, char const*) #9 0xb7eff1 in mysql_change_user_wrapper(MYSQL*, char const*, char const*, char const*) #10 0xb63882 in do_change_user(st_command*) #11 0xb5ad99 in main #12 0x7fbe8362c656 in __libc_start_call_main #13 0x7fbe8362c717 in __libc_start_main_impl #14 0x94b160 in _start ``` Squash with: D29434855 Reviewed By: jupyung Differential Revision: D43006844 fbshipit-source-id: 254272b

Summary: This fixes this leak: ``` Direct leak of 74 byte(s) in 2 object(s) allocated from: #0 0x9f235f in malloc facebook#1 0xd88f47 in my_raw_malloc(unsigned long, int) facebook#2 0xd88e1e in my_malloc(unsigned int, unsigned long, int) facebook#3 0xc183e4 in read_ok_ex facebook#4 0xc479d5 in authsm_handle_second_authenticate_user(mysql_async_auth*) facebook#5 0xc32a97 in run_plugin_auth_nonblocking(MYSQL*, char*, unsigned int, char const*, char const*, char const*, char const*, bool) facebook#6 0xc3329a in run_plugin_auth_nonblocking_wrapper facebook#7 0xbfd0de in mysql_change_user_nonblocking facebook#8 0xb7f162 in async_mysql_change_user_wrapper(MYSQL*, char const*, char const*, char const*) facebook#9 0xb7eff1 in mysql_change_user_wrapper(MYSQL*, char const*, char const*, char const*) facebook#10 0xb63882 in do_change_user(st_command*) facebook#11 0xb5ad99 in main facebook#12 0x7fbe8362c656 in __libc_start_call_main facebook#13 0x7fbe8362c717 in __libc_start_main_impl facebook#14 0x94b160 in _start ``` Squash with: D29434855 Test Plan: mtr with asandebug Reviewers: jupyung, #mysql_eng Reviewed By: jupyung Differential Revision: https://phabricator.intern.facebook.com/D43006844

Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Squash with 19345e3

Before the fix, if semisync_source plugin is installed, used, and uninstalled repeatedly, querying its status variables on a second or later installation would result in a double free error on macOS. This was because plugin uninstallation freed the histogram name variables but left their pointers around, which got picked up on the later status variable query. This was not visible under Linux because there the dynamic linker would clear the plugin variables on every load. rpl.rpl_semi_sync_alias test error under ASan: ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` Squash with 19345e3

Summary: When dump gtid_set value to string with opt_bin_log==true for Sys_var_gtid_purged_for_tailing variable, We need to hold the lock as mentioned in sql/rpl_gtid.h: https://github.com/facebook/mysql-5.6/blob/fb-mysql-8.0.23/sql/rpl_gtid.h#L2686 ``` - before starting an operation that needs to access all SIDs (e.g. Gtid_set::to_string()), hold the wrlock. ``` Squash with: RAFT SQUASH part 4 or D29372776 Test Plan: CI Callstack: executing "SHOW GLOBAL VARIABLES" statement ``` facebook#4 Gtid_set::get_string_length facebook#5 Sys_var_gtid_purged_for_tailing::global_value_ptr facebook#6 sys_var::value_ptr facebook#7 get_one_variable_ext facebook#8 System_variable::init facebook#9 System_variable::System_variable ``` Coredumps: https://fburl.com/scuba/coredumper/i1ourk9m Reviewers: mung, #mysql_eng Reviewed By: mung Subscribers: webscalesql-eng@fb.com Differential Revision: https://phabricator.intern.facebook.com/D43877444

Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 #1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 #2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 #3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 #4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 #5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 #6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 #7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 #8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 #9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 #10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 #11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 #12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 #13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 #14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 #15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 #16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 #17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 #18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 #19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 #20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 #21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 #22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 #23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 #24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 #25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 #26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) #27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) #1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 #2 0x107feba48 in my_free(void*) my_malloc.cc:141 #3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 #4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 #5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 #6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 #7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 #8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 #9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 #10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 #11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 #12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 #13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 #14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 #15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 #16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 #17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) #18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Squash with D21832889 Pull Request resolved: #1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee fbshipit-source-id: 37524d0

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 fbshipit-source-id: 8d4f7ff ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee fbshipit-source-id: 37524d0

Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Squash with D21832889 Pull Request resolved: facebook#1290 GitHub Author: Laurynas Biveinis <laurynas.biveinis@gmail.com> Test Plan: Imported from GitHub, without a `Test Plan:` line. Reviewers: chni Reviewed By: chni Subscribers: webscalesql-eng@fb.com Differential Revision: https://phabricator.intern.facebook.com/D45277600 Tags: aarch64, accept2ship

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 fbshipit-source-id: 8d4f7ff ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee fbshipit-source-id: 37524d0

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

Summary: [Porting Notes] We want to dump raft logs to vanilla async replicas regardless of whether it's the relay log or binlog. Effectively after this change we'll dump relay logs on the followers and binlogs on the leader. When the raft role changes, the logs to the dumped are also changed. Dump_log class is introduced as a thin wrapper/continer around mysql_bin_log or rli->relay_log and is inited with mysql_bin_log to emulate vanilla mysql behavior. Dump threads use the global dump_log object instead of mysql_bin_log directly. We switch the log in dump log only when raft role changes (in binlog_change_to_binlog() and binlog_change_to_apply_log()). During raft role change we take all log releated locks (LOCK_log, LOCK_index, LOCK_binlog_end_pos, and dump log lock) to serialize it with other log operations like dumping logs. Related doc - https://fb.quip.com/oTVAAdgEi4zY This diff contains below 7 patches: D23013977 D24766787 D24716539 D24900223 D24955284 D25174166 D25775525 Reviewed By: luqun Differential Revision: D26141496 ------------------------------------------------------------------------------- Passing raw_log pointer to wait_with_heartbeat() and wait_without_heartbeat() Summary: When enable_raft_plugin is OFF Dump_log::lock() is a no-op. Which means that when enable_raft_plugin is OFF there can be a race between log switching and dump threads. This could lead to a scenario where the raw_log that wait_next_event() is working on might be different than what wait_with_heartbeat()/wait_without_heartbeat() is working on. This can cause deadlocks because wait_with_heartbeat()/wait_without_heartbeat()'s mysql_cond_wait would unlock and then lock a different log's LOCK_binlog_end_pos mutex which would then never be unlocked by wait_next_event(). Reviewed By: anirbanr-fb Differential Revision: D32152658 ----------------------------------------------------------------------------------------- Fix rpl_raft_dump_raft_logs Summary: This tests completes but fails because the following warning exists: ``` 2022-08-30T16:28:00.159525Z 11 [ERROR] [MY-013114] [Repl] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replicated to the slave. Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions on master to account for transactions that have been', Error_code: MY-013114 ``` Since the MTR result file is valid, we can suppress this error. Reviewed By: yichenshen Differential Revision: D39141846 ------------------------------------------------------------------------------- Fix heap overflow in group_relay_log_name handling Summary: We were accessing group_relay_log_name in Query_log_event::do_apply_event_worker() but it's assigned only after the coordinator thread encounters an end event (i.e. xid event or a query event with "COMMIT" or "ROLLBACK" query). This was causing a race between accessing group_relay_log_name in the worker thread and writing it on the coordinator thread. We don't need to set transaction position in events other than end event, so now we set transaction position in query event only if it's an end event. The race is eliminated because group_relay_log_name is set before enqueuing the event to the worker thread (in both dep repl and vanilla mts). Reviewed By: lth Differential Revision: D28767430 ------------------------------------------------------------------------------- fix memory during MYSQL_BIN_LOG::open_existing_binlog Summary: asandebug complain there are memory leaks during MYSQL_BIN_LOG open Direct leak of 50 byte(s) in 1 object(s) allocated from: #0 0x67460ef in malloc facebook#1 0x93f0777 in my_raw_malloc(unsigned long, int) facebook#2 0x93f064a in my_malloc(unsigned int, unsigned long, int) facebook#3 0x93f0eb0 in my_strdup(unsigned int, char const*, int) facebook#4 0x8af01a6 in MYSQL_BIN_LOG::open(unsigned int, char const*, char const*, unsigned int) facebook#5 0x8af8064 in MYSQL_BIN_LOG::open_binlog(char const*, char const*, unsigned long, bool, bool, bool, Format_description_log_event*, unsigned int, RaftRotateInfo*, bool) facebook#6 0x8b00c00 in MYSQL_BIN_LOG::new_file_impl(bool, Format_description_log_event*, RaftRotateInfo*) facebook#7 0x8d65e47 in rotate_relay_log(Master_info*, bool, bool, bool, RaftRotateInfo*) facebook#8 0x8d661c0 in rotate_relay_log_for_raft(RaftRotateInfo*) facebook#9 0x8c7696a in process_raft_queue facebook#10 0xa0fa1fd in pfs_spawn_thread(void*) facebook#11 0x7f8c9a12b20b in start_thread release these memory before assign them Reviewed By: Pushapgl Differential Revision: D28819752

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

Summary: [Porting Notes] We want to dump raft logs to vanilla async replicas regardless of whether it's the relay log or binlog. Effectively after this change we'll dump relay logs on the followers and binlogs on the leader. When the raft role changes, the logs to the dumped are also changed. Dump_log class is introduced as a thin wrapper/continer around mysql_bin_log or rli->relay_log and is inited with mysql_bin_log to emulate vanilla mysql behavior. Dump threads use the global dump_log object instead of mysql_bin_log directly. We switch the log in dump log only when raft role changes (in binlog_change_to_binlog() and binlog_change_to_apply_log()). During raft role change we take all log releated locks (LOCK_log, LOCK_index, LOCK_binlog_end_pos, and dump log lock) to serialize it with other log operations like dumping logs. Related doc - https://fb.quip.com/oTVAAdgEi4zY This diff contains below 7 patches: D23013977 D24766787 D24716539 D24900223 D24955284 D25174166 D25775525 Reviewed By: luqun Differential Revision: D26141496 ------------------------------------------------------------------------------- Passing raw_log pointer to wait_with_heartbeat() and wait_without_heartbeat() Summary: When enable_raft_plugin is OFF Dump_log::lock() is a no-op. Which means that when enable_raft_plugin is OFF there can be a race between log switching and dump threads. This could lead to a scenario where the raw_log that wait_next_event() is working on might be different than what wait_with_heartbeat()/wait_without_heartbeat() is working on. This can cause deadlocks because wait_with_heartbeat()/wait_without_heartbeat()'s mysql_cond_wait would unlock and then lock a different log's LOCK_binlog_end_pos mutex which would then never be unlocked by wait_next_event(). Reviewed By: anirbanr-fb Differential Revision: D32152658 ----------------------------------------------------------------------------------------- Fix rpl_raft_dump_raft_logs Summary: This tests completes but fails because the following warning exists: ``` 2022-08-30T16:28:00.159525Z 11 [ERROR] [MY-013114] [Repl] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replicated to the slave. Suggest to replicate any transactions that master has rolled back from slave to master, and/or commit empty transactions on master to account for transactions that have been', Error_code: MY-013114 ``` Since the MTR result file is valid, we can suppress this error. Reviewed By: yichenshen Differential Revision: D39141846 ------------------------------------------------------------------------------- Fix heap overflow in group_relay_log_name handling Summary: We were accessing group_relay_log_name in Query_log_event::do_apply_event_worker() but it's assigned only after the coordinator thread encounters an end event (i.e. xid event or a query event with "COMMIT" or "ROLLBACK" query). This was causing a race between accessing group_relay_log_name in the worker thread and writing it on the coordinator thread. We don't need to set transaction position in events other than end event, so now we set transaction position in query event only if it's an end event. The race is eliminated because group_relay_log_name is set before enqueuing the event to the worker thread (in both dep repl and vanilla mts). Reviewed By: lth Differential Revision: D28767430 ------------------------------------------------------------------------------- fix memory during MYSQL_BIN_LOG::open_existing_binlog Summary: asandebug complain there are memory leaks during MYSQL_BIN_LOG open Direct leak of 50 byte(s) in 1 object(s) allocated from: #0 0x67460ef in malloc facebook#1 0x93f0777 in my_raw_malloc(unsigned long, int) facebook#2 0x93f064a in my_malloc(unsigned int, unsigned long, int) facebook#3 0x93f0eb0 in my_strdup(unsigned int, char const*, int) facebook#4 0x8af01a6 in MYSQL_BIN_LOG::open(unsigned int, char const*, char const*, unsigned int) facebook#5 0x8af8064 in MYSQL_BIN_LOG::open_binlog(char const*, char const*, unsigned long, bool, bool, bool, Format_description_log_event*, unsigned int, RaftRotateInfo*, bool) facebook#6 0x8b00c00 in MYSQL_BIN_LOG::new_file_impl(bool, Format_description_log_event*, RaftRotateInfo*) facebook#7 0x8d65e47 in rotate_relay_log(Master_info*, bool, bool, bool, RaftRotateInfo*) facebook#8 0x8d661c0 in rotate_relay_log_for_raft(RaftRotateInfo*) facebook#9 0x8c7696a in process_raft_queue facebook#10 0xa0fa1fd in pfs_spawn_thread(void*) facebook#11 0x7f8c9a12b20b in start_thread release these memory before assign them Reviewed By: Pushapgl Differential Revision: D28819752

Under load, if START SLAVE IO_THREAD and STOP SLAVE execute concurrently, the following deadlock is possible: 1) The START thread waits to acquire the channel map RW lock in shared mode and does not check whether it was signaled to quit by the STOP thread: frame facebook#5: 0x000000010075303c mysqld`Checkable_rwlock::rdlock(this=0x0000600001cd80e0) at rpl_gtid.h:464:5 frame facebook#6: 0x0000000100752168 mysqld`Multisource_info::rdlock(this=0x0000000105d2a780) at rpl_msr.h:408:25 frame facebook#7: 0x0000000100751dc8 mysqld`start_handle_slave_stats_daemon() at slave_stats_daemon.cc:233:15 frame facebook#8: 0x00000001020520ec mysqld`handle_slave_io(arg=0x000000011a869000) at rpl_replica.cc:6051:36 2) The STOP thread waits for the previous thread to stop while holding the channel map RW lock in exclusive mode: frame facebook#5: 0x0000000102072a38 mysqld`inline_mysql_cond_timedwait(that=0x000000011a869638, mutex=0x000000011a8694f0, abstime=0x00000001732d9588, src_file="/Users/laurynas/vilniusdb/myr-native-dd-proto/sql/rpl_replica.cc", src_line=2368) at mysql_cond.h:224:16 frame facebook#6: 0x0000000102050128 mysqld`terminate_slave_thread(thd=0x000000011b3ed800, term_lock=0x000000011a8694f0, term_cond=0x000000011a869638, slave_running=0x000000011a8696f4, stop_wait_timeout=0x00000001732d9700, need_lock_term=false, force=false) at rpl_replica.cc:2368:9 frame facebook#7: 0x000000010204fa6c mysqld`terminate_slave_threads(mi=0x000000011a869000, thread_mask=1, stop_wait_timeout=31536000, need_lock_term=false) at rpl_replica.cc:2204:18 frame facebook#8: 0x0000000102048020 mysqld`stop_slave(thd=0x000000011a908000, mi=0x000000011a869000, net_report=true, for_one_channel=true, push_temp_tables_warning=0x00000001732d9a37, invoked_by_raft=false) at rpl_replica.cc:10033:9 frame facebook#9: 0x0000000102048ca8 mysqld`stop_slave_cmd(thd=0x000000011a908000) at rpl_replica.cc:971:13 For the fix, observe that the starting replica I/O thread only tries to signal the stats thread to start, thus move this code to the START REPLICA command-executing thread instead, which already happens to hold the channel map lock. This also forces to move the stopping of the stats thread from the replica I/O thread to the STOP REPLICA command-executing thread. This fixes intermittent but often-seen failures on rpl.rpl_multi_source_channel_map_stress.

Under load, if START SLAVE IO_THREAD and STOP SLAVE execute concurrently, the following deadlock is possible: 1) The START thread waits to acquire the channel map RW lock in shared mode and does not check whether it was signaled to quit by the STOP thread: frame facebook#5: 0x000000010075303c mysqld`Checkable_rwlock::rdlock(this=0x0000600001cd80e0) at rpl_gtid.h:464:5 frame facebook#6: 0x0000000100752168 mysqld`Multisource_info::rdlock(this=0x0000000105d2a780) at rpl_msr.h:408:25 frame facebook#7: 0x0000000100751dc8 mysqld`start_handle_slave_stats_daemon() at slave_stats_daemon.cc:233:15 frame facebook#8: 0x00000001020520ec mysqld`handle_slave_io(arg=0x000000011a869000) at rpl_replica.cc:6051:36 2) The STOP thread waits for the previous thread to stop while holding the channel map RW lock in exclusive mode: frame facebook#5: 0x0000000102072a38 mysqld`inline_mysql_cond_timedwait(that=0x000000011a869638, mutex=0x000000011a8694f0, abstime=0x00000001732d9588, src_file="/Users/laurynas/vilniusdb/myr-native-dd-proto/sql/rpl_replica.cc", src_line=2368) at mysql_cond.h:224:16 frame facebook#6: 0x0000000102050128 mysqld`terminate_slave_thread(thd=0x000000011b3ed800, term_lock=0x000000011a8694f0, term_cond=0x000000011a869638, slave_running=0x000000011a8696f4, stop_wait_timeout=0x00000001732d9700, need_lock_term=false, force=false) at rpl_replica.cc:2368:9 frame facebook#7: 0x000000010204fa6c mysqld`terminate_slave_threads(mi=0x000000011a869000, thread_mask=1, stop_wait_timeout=31536000, need_lock_term=false) at rpl_replica.cc:2204:18 frame facebook#8: 0x0000000102048020 mysqld`stop_slave(thd=0x000000011a908000, mi=0x000000011a869000, net_report=true, for_one_channel=true, push_temp_tables_warning=0x00000001732d9a37, invoked_by_raft=false) at rpl_replica.cc:10033:9 frame facebook#9: 0x0000000102048ca8 mysqld`stop_slave_cmd(thd=0x000000011a908000) at rpl_replica.cc:971:13 For the fix, observe that the starting replica I/O thread only tries to signal the stats thread to start, thus move this code to the START REPLICA command-executing thread instead, which already happens to hold the channel map lock. This also forces to move the stopping of the stats thread from the replica I/O thread to the STOP REPLICA command-executing thread. This fixes intermittent but often-seen failures on rpl.rpl_multi_source_channel_map_stress. Squash with b015dd3

Under load, if START SLAVE IO_THREAD and STOP SLAVE execute concurrently, the following deadlock is possible: - Thread 44 is executing STOP SLAVE, has read-locked the channel map, and is waiting for the slave I/O thread to quit. - Thread 55 is executing START SLAVE, and is blocked waiting for the channel map write lock. - Thread 54 is the SLAVE I/O thread, and is trying to read-lock the channel map lock. The request of T54 is compatible with the current lock state, but according to POSIX, once a write request is pending, it is up to the implementation whether to satisfy them or block. For the fix, observe that the starting replica I/O thread only tries to signal the stats thread to start, thus move this code to the START REPLICA command-executing thread instead, which already happens to hold the channel map lock. This also forces to move the stopping of the stats thread from the replica I/O thread to the STOP REPLICA command-executing thread. This fixes intermittent but often-seen failures on rpl.rpl_multi_source_channel_map_stress under macOS. Squash with b015dd3 Stacktraces: Thread 44: frame facebook#5: 0x0000000106483108 mysqld`inline_mysql_cond_timedwait(that=0x000000014585d438, mutex=0x000000014585d2f0, abstime=0x000000016db61588, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_replica.cc", src_line=2367) at mysql_cond.h:224:16 frame facebook#6: 0x0000000106460818 mysqld`terminate_slave_thread(thd=0x00000001458fb800, term_lock=0x000000014585d2f0, term_cond=0x000000014585d438, slave_running=0x000000014585d4f4, stop_wait_timeout=0x000000016db61700, need_lock_term=false, force=false) at rpl_replica.cc:2367:9 frame facebook#7: 0x0000000106460188 mysqld`terminate_slave_threads(mi=0x000000014585ce00, thread_mask=1, stop_wait_timeout=31536000, need_lock_term=false) at rpl_replica.cc:2204:18 frame facebook#8: 0x000000010645873c mysqld`stop_slave(thd=0x0000000145952800, mi=0x000000014585ce00, net_report=true, for_one_channel=true, push_temp_tables_warning=0x000000016db61a37, invoked_by_raft=false) at rpl_replica.cc:10032:9 frame facebook#9: 0x00000001064593c4 mysqld`stop_slave_cmd(thd=0x0000000145952800) at rpl_replica.cc:971:13 Thread 55: frame facebook#2: 0x000000018e5bf73c libsystem_pthread.dylib`_pthread_rwlock_lock_slow + 720 frame facebook#3: 0x0000000104c3d2ac mysqld`native_rw_wrlock(rwp=0x00006000039dc0e8) at thr_rwlock.h:101:10 frame facebook#4: 0x0000000104c3d21c mysqld`inline_mysql_rwlock_wrlock(that=0x00006000039dc0e8, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_gtid.h", src_line=473) at mysql_rwlock.h:410:12 frame facebook#5: 0x0000000104c3c6f0 mysqld`Checkable_rwlock::wrlock(this=0x00006000039dc0e0) at rpl_gtid.h:473:5 frame facebook#6: 0x00000001054dc6e0 mysqld`Multisource_info::wrlock(this=0x000000010a182980) at rpl_msr.h:441:25 frame facebook#7: 0x0000000106458bb0 mysqld`start_slave_cmd(thd=0x0000000130008a00) at rpl_replica.cc:832:15 Thread 54: frame facebook#2: 0x000000018e5bf73c libsystem_pthread.dylib`_pthread_rwlock_lock_slow + 720 frame facebook#3: 0x0000000104b62d90 mysqld`native_rw_rdlock(rwp=0x00006000039dc0e8) at thr_rwlock.h:82:10 frame facebook#4: 0x0000000104b62d00 mysqld`inline_mysql_rwlock_rdlock(that=0x00006000039dc0e8, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_gtid.h", src_line=464) at mysql_rwlock.h:340:12 frame facebook#5: 0x0000000104b62bcc mysqld`Checkable_rwlock::rdlock(this=0x00006000039dc0e0) at rpl_gtid.h:464:5 frame facebook#6: 0x0000000104b61cec mysqld`Multisource_info::rdlock(this=0x000000010a182980) at rpl_msr.h:415:25 frame facebook#7: 0x0000000104b618f0 mysqld`start_handle_slave_stats_daemon() at slave_stats_daemon.cc:233:15 frame facebook#8: 0x00000001064627dc mysqld`handle_slave_io(arg=0x000000014585ce00) at rpl_replica.cc:6050:36

Summary: After bumping the thread stack size to 10MB for ASAN, this test started failing because the Bison parser ran out of stack before the thread did. This test deliberately tries to cause a thread stack overflow by generating an arbitrarily deeply nested SQL query to exercise the `check_stack_overrun` logic. Because our thread stack is so large in ASAN, we hit the Bison "stack" instead first. From the error log: ``` CURRENT_TEST: main.execution_constants mysqltest: At line 42: Query '$query_head 0 $query_tail' failed with wrong error 3950: 'Out of memory', should have failed with any of '0,1436' errors. ``` Parser OOM Stack: ``` (lldb) bt * thread #42, name = 'connection', stop reason = breakpoint 1.1 * frame #0: 0x000000000a33ea53 mysqld`my_error(nr=<unavailable>, MyFlags=<unavailable>) at my_error.cc:217:3 frame #1: 0x0000000008065a21 mysqld`MYSQLerror(location=<unavailable>, thd=<unavailable>, (null)=<unavailable>, s=<unavailable>) (.__uniq.242601085889238811981650692569837157750) at sql_yacc.yy:302:5 [artificial] frame #2: 0x0000000008034304 mysqld`MYSQLparse(YYTHD=<unavailable>, parse_tree=<unavailable>) at sql_yacc.cc:25323:9 frame #3: 0x0000000008009085 mysqld`THD::sql_parser(this=<unavailable>) at sql_class.cc:3811:7 frame #4: 0x00000000082b1f4c mysqld`parse_sql(thd=0x0000628000300100, parser_state=<unavailable>, creation_ctx=<unavailable>) at sql_parse.cc:7963:34 frame #5: 0x00000000082a060d mysqld`dispatch_sql_command(thd=<unavailable>, parser_state=<unavailable>, last_timer=<unavailable>) at sql_parse.cc:5993:11 frame #6: 0x000000000829bd7b mysqld`dispatch_command(thd=<unavailable>, com_data=<unavailable>, command=<unavailable>) at sql_parse.cc:2445:7 frame #7: 0x000000000829e5e9 mysqld`do_command(thd=<unavailable>) at sql_parse.cc:1636:18 frame #8: 0x00000000086c5e34 mysqld`handle_connection(arg=0x00006030001e0940) (.__uniq.188644437719200549207133117087266310382) at connection_handler_per_thread.cc:307:13 frame #9: 0x000000000b3e123b mysqld`pfs_spawn_thread(arg=0x000061600044f4a0) (.__uniq.322994040891040637281203315118403052672) at pfs.cc:2983:3 frame #10: 0x00007ffff7c9abaf libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:434:8 frame #11: 0x00007ffff7d2d17c libc.so.6`__clone3 at clone3.S:81 ``` sql/sql_yacc.yy: ``` static void MYSQLerror(YYLTYPE *location, THD *thd, Parse_tree_root **, const char *s) { if (strcmp(s, "syntax error") == 0) { thd->syntax_error_at(*location); } else if (strcmp(s, "memory exhausted") == 0) { my_error(ER_DA_OOM, MYF(0)); ... ``` mysql-fork/_build-8.0-ASanDebug/sql/sql_yacc.cc: ``` yyoverflow (YY_("memory exhausted"), &yyss1, yysize * YYSIZEOF (*yyssp), &yyvs1, yysize * YYSIZEOF (*yyvsp), &yyls1, yysize * YYSIZEOF (*yylsp), &yystacksize); ``` Differential Revision: D51233935 fbshipit-source-id: 04391603e7baef0c6e6fa4f308de0aad545474c2

Under load, if START SLAVE IO_THREAD and STOP SLAVE execute concurrently, the following deadlock is possible: - Thread 44 is executing STOP SLAVE, has read-locked the channel map, and is waiting for the slave I/O thread to quit. - Thread 55 is executing START SLAVE, and is blocked waiting for the channel map write lock. - Thread 54 is the SLAVE I/O thread, and is trying to read-lock the channel map lock. The request of T54 is compatible with the current lock state, but according to POSIX, once a write request is pending, it is up to the implementation whether to satisfy them or block. For the fix, observe that the starting replica I/O thread only tries to signal the stats thread to start, thus move this code to the START REPLICA command-executing thread instead, which already happens to hold the channel map lock. This also forces to move the stopping of the stats thread from the replica I/O thread to the STOP REPLICA command-executing thread. This fixes intermittent but often-seen failures on rpl.rpl_multi_source_channel_map_stress under macOS. Squash with b015dd3 Stacktraces: Thread 44: frame facebook#5: 0x0000000106483108 mysqld`inline_mysql_cond_timedwait(that=0x000000014585d438, mutex=0x000000014585d2f0, abstime=0x000000016db61588, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_replica.cc", src_line=2367) at mysql_cond.h:224:16 frame facebook#6: 0x0000000106460818 mysqld`terminate_slave_thread(thd=0x00000001458fb800, term_lock=0x000000014585d2f0, term_cond=0x000000014585d438, slave_running=0x000000014585d4f4, stop_wait_timeout=0x000000016db61700, need_lock_term=false, force=false) at rpl_replica.cc:2367:9 frame facebook#7: 0x0000000106460188 mysqld`terminate_slave_threads(mi=0x000000014585ce00, thread_mask=1, stop_wait_timeout=31536000, need_lock_term=false) at rpl_replica.cc:2204:18 frame facebook#8: 0x000000010645873c mysqld`stop_slave(thd=0x0000000145952800, mi=0x000000014585ce00, net_report=true, for_one_channel=true, push_temp_tables_warning=0x000000016db61a37, invoked_by_raft=false) at rpl_replica.cc:10032:9 frame facebook#9: 0x00000001064593c4 mysqld`stop_slave_cmd(thd=0x0000000145952800) at rpl_replica.cc:971:13 Thread 55: frame facebook#2: 0x000000018e5bf73c libsystem_pthread.dylib`_pthread_rwlock_lock_slow + 720 frame facebook#3: 0x0000000104c3d2ac mysqld`native_rw_wrlock(rwp=0x00006000039dc0e8) at thr_rwlock.h:101:10 frame facebook#4: 0x0000000104c3d21c mysqld`inline_mysql_rwlock_wrlock(that=0x00006000039dc0e8, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_gtid.h", src_line=473) at mysql_rwlock.h:410:12 frame facebook#5: 0x0000000104c3c6f0 mysqld`Checkable_rwlock::wrlock(this=0x00006000039dc0e0) at rpl_gtid.h:473:5 frame facebook#6: 0x00000001054dc6e0 mysqld`Multisource_info::wrlock(this=0x000000010a182980) at rpl_msr.h:441:25 frame facebook#7: 0x0000000106458bb0 mysqld`start_slave_cmd(thd=0x0000000130008a00) at rpl_replica.cc:832:15 Thread 54: frame facebook#2: 0x000000018e5bf73c libsystem_pthread.dylib`_pthread_rwlock_lock_slow + 720 frame facebook#3: 0x0000000104b62d90 mysqld`native_rw_rdlock(rwp=0x00006000039dc0e8) at thr_rwlock.h:82:10 frame facebook#4: 0x0000000104b62d00 mysqld`inline_mysql_rwlock_rdlock(that=0x00006000039dc0e8, src_file="/Users/laurynas/vilniusdb/fb-mysql/sql/rpl_gtid.h", src_line=464) at mysql_rwlock.h:340:12 frame facebook#5: 0x0000000104b62bcc mysqld`Checkable_rwlock::rdlock(this=0x00006000039dc0e0) at rpl_gtid.h:464:5 frame facebook#6: 0x0000000104b61cec mysqld`Multisource_info::rdlock(this=0x000000010a182980) at rpl_msr.h:415:25 frame facebook#7: 0x0000000104b618f0 mysqld`start_handle_slave_stats_daemon() at slave_stats_daemon.cc:233:15 frame facebook#8: 0x00000001064627dc mysqld`handle_slave_io(arg=0x000000014585ce00) at rpl_replica.cc:6050:36

Summary: add histogram for rpl_semi_sync_master_trx_wait. 8.0 porting notes: Keeps the same histogram status variables as before since these are already being read by various applications. We should eventually remove this. Reference Patch: facebook@d1a1394 Reference Patch: facebook@15333b2e6f9 Differential Revision: D21832889 ---------------------------------------------------------------------- Fix semi_sync histogram reporting Summary: Fix a porting bug with semi_sync histograms. Reviewed By: george-reynya Differential Revision: D40964563 ---------------------------------------------------------------------- Semisync histogram double free (facebook#1290) Summary: Avoid double free on latency histogram data Before this fix, rpl.rpl_semi_sync_alias test under ASan with ``` ================================================================= ==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708 READ of size 4 at 0x0001742e17d4 thread T80 #0 0x107febaec in my_free(void*) my_malloc.cc:135 facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692 facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581 facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366 facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172 facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536 facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111 facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686 facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157 facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230 facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82 facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845 facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660 facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293 facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355 facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870 facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618 facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232 facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894 facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) 0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8) freed by thread T80 here: #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269 facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141 facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668 facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517 facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516 facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833 facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123 facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192 facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602 facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731 facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323 facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093 facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444 facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636 facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307 facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983 facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4) facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c) ``` It seems that the double invocation of `free_latency_histogram_sysvars` is correct in this case, thus protect against the double free with resetting the pointers to nullptr. Pull Request resolved: facebook#1290 Reviewed By: sunshine-Chun Differential Revision: D45277600 Pulled By: hermanlee

steaphan-fb-com closed this as completed Oct 14, 2014

hermanlee mentioned this issue Sep 28, 2015

Implement repeatable read transaction isolation for RocksDB #24

Closed

mariadb-DanielLee mentioned this issue Nov 27, 2015

mysqld some times crashes at the end of Random Query Generator test #111

Closed

This was referenced Dec 8, 2015

MyRocks slave crashed because of the wrong errkey. #120

Closed

mysqld crashed when running a RQG transactions test, not reproducible at will #123

Closed

This was referenced Dec 28, 2015

handle_fatal_signal (sig=11) in thd_ha_data #129

Closed

Assertion `v->cfd_->internal_comparator().Compare(start, end) <= 0' failed. #131

Closed

rameshvs02 mentioned this issue Feb 18, 2016

InnoDB: Failing assertion: no_trx || parent_trx->is_primary in file ha_innodb.cc line 11527 #170

Closed

jtolmer mentioned this issue Feb 22, 2016

How to solve the error when compiling #42

Closed

mariadb-DanielLee mentioned this issue Apr 28, 2016

RQG test failed with a core dump #237

Closed

RickPizzi mentioned this issue Oct 21, 2016

MyRocks: 1 hour stall in DelayWrite() during bulk load #348

Closed

spetrunia mentioned this issue Nov 16, 2016

rocksdb.bulk_load test times out #428

Closed

alxyang mentioned this issue Jan 23, 2017

Flush memtable and compact L0 files for read only workloads #427

Open

laurynas-biveinis mentioned this issue Mar 14, 2017

-DWITH_ASAN=ON results in broken server if system AddressSanitizer includes LeakSanitizer #567

Closed

This was referenced Sep 21, 2017

Server asserts on startup with rocksdb-persistent-cache-size-mb #713

Open

Assertion `!rocksdb_db_options->allow_mmap_writes' failed in virtual void myrocks::Rdb_background_thread::run() #714

Open

This was referenced Oct 11, 2017

Assertion `covers_key(b)' failed in int myrocks::Rdb_key_def::cmp_full_keys(const rocks db::Slice&, const rocksdb::Slice&) #728

Closed

Start server with --rocksdb-table-cache-numshardbits=100000000 segfaults #739

Open

safe-net9 mentioned this issue Dec 6, 2017

HHVM stops at segmentation fault. #769

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problem in building on CentOS 6.4 #6

Problem in building on CentOS 6.4 #6

ktk57 commented May 23, 2014

steaphan-fb-com commented Oct 14, 2014

AllenChien commented Jul 2, 2015

AllenChien commented Jul 3, 2015

Problem in building on CentOS 6.4 #6

Problem in building on CentOS 6.4 #6

Comments

ktk57 commented May 23, 2014

steaphan-fb-com commented Oct 14, 2014

AllenChien commented Jul 2, 2015

AllenChien commented Jul 3, 2015