Skip to content
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

Closed
sbester opened this issue Feb 23, 2014 · 4 comments
Closed

crash in innobase_update_index_stats #2

sbester opened this issue Feb 23, 2014 · 4 comments
Labels

Comments

@sbester
Copy link

sbester commented Feb 23, 2014

On trunk/5.6.12 I keep hitting this crash when running random queries involving INDEX_STATISTICS.

(gdb) bt
#0  in pthread_kill () from /lib64/libpthread.so.0
#1  in handle_fatal_signal (sig=11) at ./trunk/sql/signal_handler.cc:248
#2  <signal handler called>
#3  in innobase_update_index_stats (table_stats=0x7f53740766a0) at ./trunk/storage/innobase/handler/ha_innodb.cc:4051
#4  in get_index_stats_handlerton at ./trunk/sql/handler.cc:858
#5  in plugin_foreach_with_mask at ./trunk/sql/sql_plugin.cc:2094
#6  in ha_get_index_stats at ./trunk/sql/handler.cc:866
#7  in fill_index_stats  at ./trunk/sql/table_stats.cc:681
#8  in do_fill_table at ./trunk/sql/sql_show.cc:7195
#9  in get_schema_tables_result at ./trunk/sql/sql_show.cc:7296
#10 in JOIN::prepare_result at ./trunk/sql/sql_select.cc:844
#11 in JOIN::exec at ./trunk/sql/sql_executor.cc:116
#12 in mysql_execute_select  at ./trunk/sql/sql_select.cc:1121
#13 in mysql_select at ./trunk/sql/sql_select.cc:1242
#14 in handle_select at ./trunk/sql/sql_select.cc:125
#15 in execute_sqlcom_select at ./trunk/sql/sql_parse.cc:5534
#16 in mysql_execute_command at ./trunk/sql/sql_parse.cc:2969
#17 in mysql_parse at ./trunk/sql/sql_parse.cc:6694
#18 in dispatch_command at ./trunk/sql/sql_parse.cc:1402
#19 in do_command at ./trunk/sql/sql_parse.cc:1047
#20 in do_handle_one_connection  at ./trunk/sql/sql_connect.cc:1001
#21 in handle_one_connection at ./trunk/sql/sql_connect.cc:917
#22 in pfs_spawn_thread at ./trunk/storage/perfschema/pfs.cc:1855
#23 in start_thread from /lib64/libpthread.so.0
#24 in clone from /lib64/libc.so.6
(gdb) p mysql_parse::thd->query_string
$1 = {
  string = {
    str = 0x7f5374006c40 "select  \t ROUTINE_BODY from\n\t`information_schema`.`INNODB_SYS_FOREIGN` as `INNODB_SYS_FOREIGN` \n\t right outer join `information_schema`.`INDEX_STATISTICS` as `INDEX_STATISTICS` \non 2\n\n \t\n\t natural left outer join `information_schema`.`ROUTINES` as `ROUTINES` \n \t\n\t inner join `test`.`t0004` as `t0004`  \non ( 1  )\n  \n \ngroup by \n\tROUTINES.DEFINER desc",
    length = 351
  },
  cs = 0x1309180 <my_charset_latin1>
}
(gdb)

I have many core files but no exact testcase yet. Rerunning queries didn't crash.
More info later.

@sbester
Copy link
Author

sbester commented Feb 23, 2014

Version: '5.6.12'  socket: 'sock'  port: 3306  MySQL Community Server (GPL)
==27811== Thread 24:
==27811== Conditional jump or move depends on uninitialised value(s)
==27811==    at 0x5E87C1: fill_index_stats(THD*, TABLE_LIST*, Item*) (table_stats.cc:692)
==27811==    by 0x757581: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:7195)
==27811==    by 0x73A884: JOIN::prepare_result(List<Item>**) (sql_select.cc:844)
==27811==    by 0x6F8B5B: JOIN::exec() (sql_executor.cc:116)
==27811==    by 0x73EB14: mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, SQL_I_List<st_order>*, SQL_I_List<st_order>*, Item*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:1121)
==27811==    by 0x73F403: handle_select(THD*, select_result*, unsigned long) (sql_select.cc:125)
==27811==    by 0x5A7DEF: execute_sqlcom_select(THD*, TABLE_LIST*, unsigned long long*) [clone .isra.149] (sql_parse.cc:5534)
==27811==    by 0x71C349: mysql_execute_command(THD*, unsigned long long*, unsigned long long*) (sql_parse.cc:2969)
==27811==    by 0x72081E: mysql_parse(THD*, char*, unsigned int, Parser_state*, unsigned long long*, char*) (sql_parse.cc:6694)
==27811==    by 0x721E8A: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1402)
==27811==    by 0x6F0181: do_handle_one_connection(THD*) (sql_connect.cc:1001)
==27811==    by 0x6F022F: handle_one_connection (sql_connect.cc:917)
==27811==    by 0x3537607D13: start_thread (pthread_create.c:309)
==27811==    by 0x35372F168C: clone (clone.S:115)

0x00000000005e87c1 in fill_index_stats (thd=thd@entry=0x13adf890, tables=tables@entry=0x13aef538, cond=<optimized out>) at /home/sbester/build/facebook/mysql-5.6/trunk/sql/table_stats.cc:692
692               index_stats->rows_requested == 0 &&
(gdb) p *index_stats
$1 = {
  name = "PRIMARY", '\000' <repeats 185 times>,
  rows_inserted = 0,
  rows_updated = 0,
  rows_deleted = 0,
  rows_read = 0,
  rows_requested = 0,
  rows_index_first = 0,
  rows_index_next = 0,
  io_perf_read = {
    bytes = 0,
    requests = 0,
    svc_time = 0,
    svc_time_max = 0,
    wait_time = 0,
    wait_time_max = 0,
    slow_ios = 0
  },
  n_pages = 0,
  n_pages_freed = 0,
  n_btr_compress = 0,
  n_btr_compress_failure = 0,
  n_page_split = 0
}
(gdb) p mysql_parse::thd->query_string
$2 = {
  string = {
    str = 0x13ed99a0 "select  IS_HASHED from `information_schema`.`INNODB_SYS_TABLESPACES` as `INNODB_SYS_TABLESPACES` cross join `information_schema`.`PROCESSLIST` as `PROCESSLIST`  on (INNODB_SYS_TABLESPACES.FLAG && PROCESSLIST.DB ) inner join `information_schema`.`INNODB_BUFFER_PAGE_LRU` as `INNODB_BUFFER_PAGE_LRU`  on (INNODB_SYS_TABLESPACES.FLAG is not null ) inner join `information_schema`.`INDEX_STATISTICS` as `INDEX_STATISTICS` on (INNODB_SYS_TABLESPACES.NAME <=> INDEX_STATISTICS.IO_READ_SLOW_IOS )",
    length = 489
  },
  cs = 0x138a1e0
}

@sbester
Copy link
Author

sbester commented Feb 23, 2014

Testcase.....

drop procedure if exists p1;
delimiter $
create procedure p1()
begin
  declare continue handler for sqlexception begin end;
  repeat
    if rand()>0.5 then drop table if exists t1; end if;
    if rand()>0.5 then create table if not exists `t1`(`a` int primary key,b char(1), key(b))engine=innodb; end if;
    if rand()>0.5 then select  IS_HASHED from `information_schema`.`INNODB_SYS_TABLESPACES` as `INNODB_SYS_TABLESPACES` cross join `information_schema`.`PROCESSLIST` as `PROCESSLIST`  on (INNODB_SYS_TABLESPACES.FLAG && PROCESSLIST.DB ) inner join `information_schema`.`INNODB_BUFFER_PAGE_LRU` as `INNODB_BUFFER_PAGE_LRU`  on (INNODB_SYS_TABLESPACES.FLAG is not null ) inner join `information_schema`.`INDEX_STATISTICS` as `INDEX_STATISTICS` on (INNODB_SYS_TABLESPACES.NAME <=> INDEX_STATISTICS.IO_READ_SLOW_IOS ) into @a; end if;
    if rand()>0.5 then select  ROUTINE_BODY from `information_schema`.`INNODB_SYS_FOREIGN` as `INNODB_SYS_FOREIGN`  right outer join `information_schema`.`INDEX_STATISTICS` as `INDEX_STATISTICS` on 2  natural left outer join `information_schema`.`ROUTINES` as `ROUTINES`  inner join t1  on ( 1  )group by ROUTINES.DEFINER desc into @a; end if;
    if rand()>0.5 then flush tables; end if;
    if rand()>0.5 then rename table t1 to t2; end if;
    if rand()>0.5 then rename table t2 to t1; end if;
    if rand()>0.5 then alter table t1 add key g(b); end if;
    if rand()>0.5 then alter table t1 add key g(a); end if;
    if rand()>0.5 then alter table t1 drop key g; end if;
    if rand()>0.5 then select * from `information_schema`.`INDEX_STATISTICS`; end if;
  until 1=2 end repeat;
 end $

 delimiter ;
  call p1();

@steaphan-fb-com
Copy link

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!

@steaphan-fb-com
Copy link

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.

hermanlee pushed a commit that referenced this issue Sep 14, 2015
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
maykov added a commit that referenced this issue Sep 14, 2015
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
spetrunia added a commit that referenced this issue Jan 5, 2016
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
yoshinorim added a commit that referenced this issue Mar 23, 2016
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
hermanlee pushed a commit that referenced this issue Jan 31, 2017
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.
hermanlee pushed a commit that referenced this issue Jan 31, 2017
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
hermanlee pushed a commit that referenced this issue Jan 31, 2017
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
VitaliyLi pushed a commit to VitaliyLi/mysql-5.6 that referenced this issue Feb 9, 2017
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
VitaliyLi pushed a commit to VitaliyLi/mysql-5.6 that referenced this issue Feb 9, 2017
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
facebook-github-bot pushed a commit that referenced this issue Jun 12, 2017
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
facebook-github-bot pushed a commit that referenced this issue Jun 13, 2017
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
facebook-github-bot pushed a commit that referenced this issue Jun 13, 2017
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
laurynas-biveinis added a commit to laurynas-biveinis/mysql-5.6 that referenced this issue Nov 28, 2023
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
facebook-github-bot pushed a commit that referenced this issue Mar 18, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Apr 23, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Apr 23, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Apr 25, 2024
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
sunxiayi pushed a commit to sunxiayi/mysql-5.6 that referenced this issue Apr 30, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 7, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 8, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 9, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 10, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 13, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 15, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 16, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 17, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 17, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 21, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 21, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 30, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 20, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 21, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 25, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jul 2, 2024
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
facebook-github-bot pushed a commit that referenced this issue Jul 18, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jul 19, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jul 19, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jul 31, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 2, 2024
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
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 6, 2024
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
sunshine-Chun pushed a commit to sunshine-Chun/mysql-5.6 that referenced this issue Sep 4, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants