-
Notifications
You must be signed in to change notification settings - Fork 713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crash in innobase_update_index_stats #2
Comments
|
Testcase.....
|
Thanks for the detailed info. Sorry for the crash bug - we've actually already fixed this in our current dev branch, which is based on 5.6.16. We just haven't had a chance to push an updated version here yet. We should be pushing a completely up-to-date branch up here some time in the next few weeks. Once we do, we'd certainly love any more feedback you have. Again, thanks! |
Now that WebScaleSQL is public, we also pushed our 5.6.16 branch (which is based on WebScaleSQL now). That includes a fix for this bug. |
Summary: Inside index_next_same() call, we should 1. first check whether the record matches the index lookup prefix, 2. then check pushed index condition. If we try to check #2 without checking #1 first, we may walk off the index lookup prefix and scan till the end of the index. Test Plan: Run mtr Reviewers: hermanlee4, maykov, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D38769
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: Inside index_next_same() call, we should 1. first check whether the record matches the index lookup prefix, 2. then check pushed index condition. If we try to check #2 without checking #1 first, we may walk off the index lookup prefix and scan till the end of the index. Test Plan: Run mtr Reviewers: hermanlee4, maykov, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D38769
Summary: MyRocks had two bugs when calculating index scan cost. 1. block_size was not considered. This made covering index scan cost (both full index scan and range scan) much higher 2. ha_rocksdb::records_in_range() may have estimated more rows than the estimated number of rows in the table. This was wrong, and MySQL optimizer decided to use full index scan even though range scan was more efficient. This diff fixes #1 by setting stats.block_size at ha_rocksdb::open(), and fixes #2 by reducing the number of estimated rows if it was larger than stats.records. Test Plan: mtr, updating some affected test cases, and new test case rocksdb_range2 Reviewers: hermanlee4, jkedgar, spetrunia Reviewed By: spetrunia Subscribers: MarkCallaghan, webscalesql-eng Differential Revision: https://reviews.facebook.net/D55869
Problem: The binary log group commit sync is failing when committing a group of transactions into a non-transactional storage engine while other thread is rotating the binary log. Analysis: The binary log group commit procedure (ordered_commit) acquires LOCK_log during the #1 stage (flush). As it holds the LOCK_log, a binary log rotation will have to wait until this flush stage to finish before actually rotating the binary log. For the #2 stage (sync), the binary log group commit only holds the LOCK_log if sync_binlog=1. In this case, the rotation has to wait also for the sync stage to finish. When sync_binlog>1, the sync stage releases the LOCK_log (to let other groups to enter the flush stage), holding only the LOCK_sync. In this case, the rotation can acquire the LOCK_log in parallel with the sync stage. For commits into transactional storage engine, the binary log rotation checks a counter of "flushed but not yet committed" transactions, waiting until this counter to be zeroed before closing the current binary log file. As the commit of the transactions happen in the #3 stage of the binary log group commit, the sync of the binary log in stage #2 always succeed. For commits into non-transactional storage engine, the binary log rotation is checking the "flushed but not yet committed" transactions counter, but it is zero because it only counts transactions that contains XIDs. So, the rotation is allowed to take place in parallel with the #2 stage of the binary log group commit. When the sync is called at the same time that the rotation has closed the old binary log file but didn't open the new file yet, the sync is failing with the following error: 'Can't sync file 'UNOPENED' to disk (Errcode: 9 - Bad file descriptor)'. Fix: For non-transactional only workload, binary log group commit will keep the LOCK_log when entering #2 stage (sync) if the current group is supposed to be synced to the binary log file.
Summary: Inside index_next_same() call, we should 1. first check whether the record matches the index lookup prefix, 2. then check pushed index condition. If we try to check #2 without checking #1 first, we may walk off the index lookup prefix and scan till the end of the index. Test Plan: Run mtr Reviewers: hermanlee4, maykov, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D38769
Summary: MyRocks had two bugs when calculating index scan cost. 1. block_size was not considered. This made covering index scan cost (both full index scan and range scan) much higher 2. ha_rocksdb::records_in_range() may have estimated more rows than the estimated number of rows in the table. This was wrong, and MySQL optimizer decided to use full index scan even though range scan was more efficient. This diff fixes #1 by setting stats.block_size at ha_rocksdb::open(), and fixes #2 by reducing the number of estimated rows if it was larger than stats.records. Test Plan: mtr, updating some affected test cases, and new test case rocksdb_range2 Reviewers: hermanlee4, jkedgar, spetrunia Reviewed By: spetrunia Subscribers: MarkCallaghan, webscalesql-eng Differential Revision: https://reviews.facebook.net/D55869
Summary: Inside index_next_same() call, we should 1. first check whether the record matches the index lookup prefix, 2. then check pushed index condition. If we try to check facebook#2 without checking facebook#1 first, we may walk off the index lookup prefix and scan till the end of the index. Test Plan: Run mtr Reviewers: hermanlee4, maykov, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D38769
Summary: MyRocks had two bugs when calculating index scan cost. 1. block_size was not considered. This made covering index scan cost (both full index scan and range scan) much higher 2. ha_rocksdb::records_in_range() may have estimated more rows than the estimated number of rows in the table. This was wrong, and MySQL optimizer decided to use full index scan even though range scan was more efficient. This diff fixes facebook#1 by setting stats.block_size at ha_rocksdb::open(), and fixes facebook#2 by reducing the number of estimated rows if it was larger than stats.records. Test Plan: mtr, updating some affected test cases, and new test case rocksdb_range2 Reviewers: hermanlee4, jkedgar, spetrunia Reviewed By: spetrunia Subscribers: MarkCallaghan, webscalesql-eng Differential Revision: https://reviews.facebook.net/D55869
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
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: When COUNT(*) style aggregation appears in queries, the optimizer realizes that a full scan needs to be done. The index doesn't matter - any index will do as it long it satisfies the other query predicates present. There are two heuristics at play. If there is a choice of multiple indexes, the optimizer will pick the index that has the shortest length since that means less disk scan time, therefore faster query (heuristic #1). In the case of vector indexes, the current design can have the vector field present in the clustered PK as well as the vector index (eg the flat index). Even though there's no clear advantage, the heuristic is based on INNODB style index layout, and assumes that a secondary index will always be a better choice as long as it does not cover all table columns (heuristic #2). In reality, in both INNODB and MyRocks, the secondary key does contain the PK. But this fact is ignored. What ends up happening is that by only considered the # of explicitly defined key parts, the vector index ends up getting picked up. In the case of the IVF index, the vector index may be shorter than the primary clustered index. Thus secondary index will have a shorter key length than the primary, and will end up getting picked up (i.e. if the key part heuristic doesn't already pick the vector index again). There can be many other index combinations. We want the optimizer to pick another available index. If no other index is available, then pick the primary clustered index. Differential Revision: D55003211 fbshipit-source-id: 5ce6b34
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: 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: 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: When COUNT(*) style aggregation appears in queries, the optimizer realizes that a full scan needs to be done. The index doesn't matter - any index will do as it long it satisfies the other query predicates present. There are two heuristics at play. If there is a choice of multiple indexes, the optimizer will pick the index that has the shortest length since that means less disk scan time, therefore faster query (heuristic facebook#1). In the case of vector indexes, the current design can have the vector field present in the clustered PK as well as the vector index (eg the flat index). Even though there's no clear advantage, the heuristic is based on INNODB style index layout, and assumes that a secondary index will always be a better choice as long as it does not cover all table columns (heuristic facebook#2). In reality, in both INNODB and MyRocks, the secondary key does contain the PK. But this fact is ignored. What ends up happening is that by only considered the # of explicitly defined key parts, the vector index ends up getting picked up. In the case of the IVF index, the vector index may be shorter than the primary clustered index. Thus secondary index will have a shorter key length than the primary, and will end up getting picked up (i.e. if the key part heuristic doesn't already pick the vector index again). There can be many other index combinations. We want the optimizer to pick another available index. If no other index is available, then pick the primary clustered index. Test Plan: MTR Reviewers: rpan, arahut, #mysql_eng Reviewed By: rpan Subscribers: icai Differential Revision: https://phabricator.intern.facebook.com/D55003211 Tasks: T182347836
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: There were two problems with the existing code that caused missed notification such that `wait_for_all_committing_trxs_to_finish()` waited forever: 1. In group commit the follower threads were incrementing committing trxs without holding LOCK_log which meant that the counter could increment after going down to 0 and since the counter doesn't use mutex (it's atomic) there can be a race such that the predicate check while waiting fails and we never notify after so we're stuck. Another problem with this was that the counter can go to 0 if only the leader thread decrements it before the followers have the chance to increment it. This will cause us to wake up before all trxs are actually finished. 2. Since we don't hold a mutex while inc and dec the counter there can be a race such that the waiting thread fails the predicate on a non-zero counter, then before we go into waiting, the counter is dec to 0 and we notify. But since the notification happened before we went into waiting we miss it completely and wait forever. To fix #1 we make sure that we increment the counter only while holding LOCK_log. To fix #2 we take a mutex before notifying when the counter goes to 0, this way the notification will be either entirely before or after the wait. Out of paranoia also added a gvar to skip waiting altogether and converted the wait() to a wait_for(). Differential Revision: D59882151 fbshipit-source-id: d60dc70
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: 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: 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: 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: 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: There were two problems with the existing code that caused missed notification such that `wait_for_all_committing_trxs_to_finish()` waited forever: 1. In group commit the follower threads were incrementing committing trxs without holding LOCK_log which meant that the counter could increment after going down to 0 and since the counter doesn't use mutex (it's atomic) there can be a race such that the predicate check while waiting fails and we never notify after so we're stuck. Another problem with this was that the counter can go to 0 if only the leader thread decrements it before the followers have the chance to increment it. This will cause us to wake up before all trxs are actually finished. 2. Since we don't hold a mutex while inc and dec the counter there can be a race such that the waiting thread fails the predicate on a non-zero counter, then before we go into waiting, the counter is dec to 0 and we notify. But since the notification happened before we went into waiting we miss it completely and wait forever. To fix facebook#1 we make sure that we increment the counter only while holding LOCK_log. To fix facebook#2 we take a mutex before notifying when the counter goes to 0, this way the notification will be either entirely before or after the wait. Out of paranoia also added a gvar to skip waiting altogether and converted the wait() to a wait_for(). Test Plan: Ran a mysqlslap with high concurrency on both primary and replica and created snapshots on loop. Also exiting mtr for functional testing. Reviewers: yoshinori, yichenshen Reviewed By: yichenshen Differential Revision: https://phabricator.intern.facebook.com/D59882151
On trunk/5.6.12 I keep hitting this crash when running random queries involving INDEX_STATISTICS.
I have many core files but no exact testcase yet. Rerunning queries didn't crash.
More info later.
The text was updated successfully, but these errors were encountered: