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.

Sign up for GitHub

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

Jump to bottom

[CLOSED] change SHOW ENGINE ROCKSDB STATUS #22

Closed
hermanlee opened this issue Sep 28, 2015 · 0 comments
Closed

[CLOSED] change SHOW ENGINE ROCKSDB STATUS #22

hermanlee opened this issue Sep 28, 2015 · 0 comments

Comments

@hermanlee
Copy link
Contributor

Issue by jonahcohen
Wednesday Jan 07, 2015 at 22:57 GMT
Originally opened as MySQLOnRocksDB#4

From @mdcallag:

For background see http://dev.mysql.com/doc/refman/5.6/en/show-engine.html

We need to change what is in SHOW ENGINE ROCKSDB STATUS. Right now it has live sst files which is a huge list with leveled compaction. For now I prefer to have it list the output from compaction stats. That probably needs to use one of:
db->GetProperty("rocksdb.stats", ...
db->GetProperty("rocksdb.cfstats", ...

*************************** 1. row ***************************
Type: ROCKSDB
Name: live_files
Status: cf=default name=/4908814.sst size=97853952
cf=default name=/4908812.sst size=97879865
cf=default name=/4908807.sst size=97833748
cf=default name=/4905498.sst size=1865749
cf=default name=/4905500.sst size=2670668
This was referenced Dec 28, 2015
Closed
Closed
spetrunia added a commit that referenced this issue Jan 5, 2016
@spetrunia @jtolmer
Issue #22: SELECT ... FOR UPDATE takes a long time
5057fde 
- Specify the right column family when making a rocksdb::Get() call.
@mariadb-DanielLee mariadb-DanielLee mentioned this issue Apr 28, 2016
Closed
@RickPizzi RickPizzi mentioned this issue Oct 21, 2016
Closed
@spetrunia spetrunia mentioned this issue Nov 16, 2016
Closed
@alxyang alxyang mentioned this issue Jan 23, 2017
Open
hermanlee pushed a commit that referenced this issue Jan 31, 2017
@spetrunia
Issue #22: SELECT ... FOR UPDATE takes a long time
c63319f 
- Specify the right column family when making a rocksdb::Get() call.
VitaliyLi pushed a commit to VitaliyLi/mysql-5.6 that referenced this issue Feb 9, 2017
@spetrunia @jkedgar
Issue facebook#22: SELECT ... FOR UPDATE takes a long time
cac1f42 
- Specify the right column family when making a rocksdb::Get() call.
@george-lorch george-lorch mentioned this issue Oct 11, 2017
Closed
@safe-net9 safe-net9 mentioned this issue Dec 6, 2017
Closed
@RoelVdP RoelVdP mentioned this issue Dec 31, 2017
Closed
@george-lorch george-lorch mentioned this issue Jan 10, 2018
Closed
@TenderWang TenderWang mentioned this issue Apr 26, 2018
Closed
@george-lorch george-lorch mentioned this issue Nov 1, 2018
Closed
facebook-github-bot pushed a commit that referenced this issue Dec 23, 2019
@spetrunia @facebook-github-bot
Issue #22: SELECT ... FOR UPDATE takes a long time - Specify the righ…
9f61583 
…t column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 12, 2020
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
295cc11 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 9, 2020
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
587bcd5 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 16, 2020
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
f3b0302 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Oct 5, 2020
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
80e9030 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Nov 11, 2020
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
1bfd816 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: f528c4c
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Mar 11, 2021
@spetrunia @facebook-github-bot
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
4357b5e 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: 29a2cdee995
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 16, 2021
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
1556feb 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: 29a2cdee995
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 30, 2021
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
8c60729 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: 29a2cdee995
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 1, 2021
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
fa9ed8b 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: 29a2cdee995
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 2, 2021
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
0d73edb 
…the right column family when making a rocksdb::Get() call.

fbshipit-source-id: 29a2cdee995
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jan 17, 2022
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
db38fe5 
…the right column family when making a rocksdb::Get() call.
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Apr 26, 2022
@spetrunia
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
309a85d 
…the right column family when making a rocksdb::Get() call.
laurynas-biveinis pushed a commit to laurynas-biveinis/mysql-5.6 that referenced this issue Aug 11, 2022
@spetrunia
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
747af22 
…the right column family when making a rocksdb::Get() call.
laurynas-biveinis added a commit to laurynas-biveinis/mysql-5.6 that referenced this issue Apr 5, 2023
@laurynas-biveinis
Avoid double free on latency histogram data
5cf9142 
Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Squash with 19345e3
laurynas-biveinis added a commit to laurynas-biveinis/mysql-5.6 that referenced this issue Apr 25, 2023
@laurynas-biveinis
Avoid double free on latency histogram data
b4f9933 
Before the fix, if semisync_source plugin is installed, used, and uninstalled
repeatedly, querying its status variables on a second or later installation
would result in a double free error on macOS. This was because plugin
uninstallation freed the histogram name variables but left their pointers
around, which got picked up on the later status variable query. This was not
visible under Linux because there the dynamic linker would clear the plugin
variables on every load.

rpl.rpl_semi_sync_alias test error under ASan:

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

Squash with 19345e3
facebook-github-bot pushed a commit that referenced this issue Apr 28, 2023
@laurynas-biveinis @facebook-github-bot
Semisync histogram double free (#1290)
4b39a6d 
Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    #1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    #2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    #3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    #4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    #5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    #6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    #7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    #8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    #9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    #10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    #11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    #12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    #13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    #14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    #15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    #16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    #17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    #18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    #19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    #20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    #21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    #22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    #23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    #24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    #25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    #26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    #27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    #1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    #2 0x107feba48 in my_free(void*) my_malloc.cc:141
    #3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    #4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    #5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    #6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    #7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    #8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    #9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    #10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    #11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    #12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    #13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    #14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    #15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    #16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    #17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    #18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Squash with D21832889

Pull Request resolved: #1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 17, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
c3c7172 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 18, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
9057de3 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 26, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
905e584 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 1, 2023
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
dabaf16 
…the right column family when making a rocksdb::Get() call.
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 1, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
55c3e32 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
luqun pushed a commit to luqun/mysql-5.6 that referenced this issue Jun 5, 2023
@hermanlee
[mysql-5.6][PR] Semisync histogram double free
37524d0 
Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Squash with D21832889

Pull Request resolved: facebook#1290
GitHub Author: Laurynas Biveinis <laurynas.biveinis@gmail.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.

Reviewers: chni

Reviewed By: chni

Subscribers: webscalesql-eng@fb.com

Differential Revision: https://phabricator.intern.facebook.com/D45277600

Tags: aarch64, accept2ship
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 14, 2023
@spetrunia @inikep
Issue facebook#22: SELECT ... FOR UPDATE takes a long time - Specify …
1684fdf 
…the right column family when making a rocksdb::Get() call.
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 14, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
44701b4 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 19, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
8f93dbd 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 23, 2023
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
ebdfd20 
Summary:
add histogram for rpl_semi_sync_master_trx_wait.

8.0 porting notes: Keeps the same histogram status variables as before
since these are already being read by various applications. We should
eventually remove this.

Reference Patch: facebook@d1a1394
Reference Patch: facebook@15333b2e6f9

Differential Revision: D21832889

----------------------------------------------------------------------

Fix semi_sync histogram reporting

Summary:
Fix a porting bug with semi_sync histograms.

Reviewed By: george-reynya

Differential Revision: D40964563

fbshipit-source-id: 8d4f7ff

----------------------------------------------------------------------

Semisync histogram double free (facebook#1290)

Summary:
Avoid double free on latency histogram data

Before this fix, rpl.rpl_semi_sync_alias test under ASan with

```
=================================================================
==65389==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001742e17d4 at pc 0x000107febaf0 bp 0x00016ea8f710 sp 0x00016ea8f708
READ of size 4 at 0x0001742e17d4 thread T80
    #0 0x107febaec in my_free(void*) my_malloc.cc:135
    facebook#1 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#2 0x103cb99bc in prepare_latency_histogram_vars(latency_histogram*, SHOW_VAR*, unsigned long long*) mysqld.cc:4692
    facebook#3 0x17c65826c in rpl_semi_sync_master_trx_wait_histogram(THD*, SHOW_VAR*, char*) semisync_source_plugin.cc:581
    facebook#4 0x10be1b4cc in PFS_status_variable_cache::manifest(THD*, SHOW_VAR const*, System_status_var*, char const*, bool, bool) pfs_variable.cc:1366
    facebook#5 0x10be1ba90 in PFS_status_variable_cache::do_materialize_all(THD*) pfs_variable.cc:1172
    facebook#6 0x10c0ab33c in PFS_variable_cache<Status_variable>::materialize_all(THD*) pfs_variable.h:536
    facebook#7 0x10c0ab294 in table_session_status::rnd_init(bool) table_session_status.cc:111
    facebook#8 0x10bceb790 in ha_perfschema::rnd_init(bool) ha_perfschema.cc:1686
    facebook#9 0x1033c7cec in handler::ha_rnd_init(bool) handler.cc:3157
    facebook#10 0x103975380 in TableScanIterator::Init() basic_row_iterators.cc:230
    facebook#11 0x103a33a18 in FilterIterator::Init() composite_iterators.h:82
    facebook#12 0x103982ec0 in MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*) composite_iterators.cc:845
    facebook#13 0x103981410 in MaterializeIterator::Init() composite_iterators.cc:660
    facebook#14 0x1049fc518 in Query_expression::ExecuteIteratorQuery(THD*) sql_union.cc:1293
    facebook#15 0x1049fd358 in Query_expression::execute(THD*) sql_union.cc:1355
    facebook#16 0x1047ae7ac in Sql_cmd_dml::execute_inner(THD*) sql_select.cc:870
    facebook#17 0x1047ac344 in Sql_cmd_dml::execute(THD*) sql_select.cc:618
    facebook#18 0x1047ffcc8 in Sql_cmd_show::execute(THD*) sql_show.cc:232
    facebook#19 0x10480ab58 in Sql_cmd_show_status::execute(THD*) sql_show.cc:894
    facebook#20 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#21 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#22 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#23 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#24 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#25 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#26 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#27 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)

0x0001742e17d4 is located 4 bytes inside of 40-byte region [0x0001742e17d0,0x0001742e17f8)
freed by thread T80 here:
    #0 0x139ff6de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
    facebook#1 0x107febcfc in my_raw_free(void*) my_malloc.cc:269
    facebook#2 0x107feba48 in my_free(void*) my_malloc.cc:141
    facebook#3 0x103cb9828 in free_latency_histogram_sysvars(SHOW_VAR*) mysqld.cc:4668
    facebook#4 0x17c6231e8 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:517
    facebook#5 0x17c623488 in ReplSemiSyncMaster::~ReplSemiSyncMaster() semisync_source.cc:516
    facebook#6 0x17c651484 in semi_sync_master_plugin_deinit(void*) semisync_source_plugin.cc:833
    facebook#7 0x10467aa90 in plugin_deinitialize(st_plugin_int*, bool) sql_plugin.cc:1123
    facebook#8 0x1046730b0 in reap_plugins() sql_plugin.cc:1192
    facebook#9 0x1046863b4 in mysql_uninstall_plugin(THD*, MYSQL_LEX_CSTRING) sql_plugin.cc:2602
    facebook#10 0x104685374 in Sql_cmd_uninstall_plugin::execute(THD*) sql_plugin.cc:3731
    facebook#11 0x1045cea6c in mysql_execute_command(THD*, bool, unsigned long long*) sql_parse.cc:5323
    facebook#12 0x1045c5dcc in dispatch_sql_command(THD*, Parser_state*, unsigned long long*) sql_parse.cc:6093
    facebook#13 0x1045bb92c in dispatch_command(THD*, COM_DATA const*, enum_server_command) sql_parse.cc:2444
    facebook#14 0x1045c06f8 in do_command(THD*) sql_parse.cc:1636
    facebook#15 0x104cc4cc4 in handle_connection(void*) connection_handler_per_thread.cc:307
    facebook#16 0x10bd130d4 in pfs_spawn_thread(void*) pfs.cc:2983
    facebook#17 0x18ad47fa4 in _pthread_start+0x90 (libsystem_pthread.dylib:arm64e+0x6fa4)
    facebook#18 0x18ad42d9c in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d9c)
```

It seems that the double invocation of `free_latency_histogram_sysvars` is
correct in this case, thus protect against the double free with resetting the
pointers to nullptr.

Pull Request resolved: facebook#1290

Reviewed By: sunshine-Chun

Differential Revision: D45277600

Pulled By: hermanlee

fbshipit-source-id: 37524d0
hermanlee pushed a commit to hermanlee/mysql-5.6 that referenced this issue Oct 3, 2023
@santoshbanda
add histogram for rpl_semi_sync_master_trx_wait
b228797 
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
hermanlee pushed a commit to hermanlee/mysql-5.6 that referenced this issue Oct 18, 2023
@santoshbanda
add histogram for rpl_semi_sync_master_trx_wait
2e6bfe5 
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
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
95b3cd6 
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
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
3dce2f6 
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
@santoshbanda @inikep
add histogram for rpl_semi_sync_master_trx_wait
f6997e7 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@hermanlee