[MDEV-30949] Direct leak in my_register_filename / binlog_online_alter_end_trans - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Affects Version/s: N/A
Fix Version/s: 11.2.1
Component/s: Data Definition - Alter Table
Labels:
None

Description

The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough --repeat=N. Also with --force-restart!

REPEAT in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role JSON_TABLE plays, possibly the same.

CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;

INSERT INTO t VALUES (NULL);

--connect (con1,localhost,root,,)

--send

  ALTER TABLE t FORCE, ALGORITHM=COPY;

--connection default

INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;

--connection con1

--reap

DROP TABLE t;

bb-11.0-oalter e599b8b458
Warning: Memory not freed: 96

=================================================================
==2695459==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
#2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
#3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
#4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
#5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
#6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
#7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
#8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
#9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
#10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
#11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
#12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
#13 0x5584f1391157 in Event_log::write_cache(THD, st_io_cache) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
#14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
#15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
#16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
#17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
#18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
#19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
#20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
#21 0x5584f076bd4c in mysql_parse(THD, char, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
#22 0x5584f0741f44 in dispatch_command(enum_server_command, THD, char, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
#23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
#24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
#25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
#26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
#27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442

SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
230329 0:36:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
read_buffer_size=131072
max_used_connections=2
thread_count=0
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x100000
sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385809 385809 processes
Max open files 1024 1024 files
Max locked memory 12649951232 12649951232 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385809 385809 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

Fatal signal 11 while backtracing

Not reproducible on the baseline.

Attachments

Issue Links

is caused by

MDEV-16329 Engine-independent online ALTER TABLE

Closed

relates to

MDEV-28808 Test MDEV-16329 (ALTER ONLINE TABLE) - Core server part

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2023-03-28 21:45

Elena Stepanova made changes - 2023-03-28 21:45

Field	Original Value	New Value
Link		This issue is caused by ~~MDEV-16329~~ [ ~~MDEV-16329~~ ]

Elena Stepanova made changes - 2023-03-28 21:46

Description

The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough {{--repeat=N}}. *Also with {{--force-restart}}!*

{{REPEAT}} in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role {{JSON_TABLE}} plays, possibly the same.

{code:sql}
CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;
INSERT INTO t VALUES (NULL);

--connect (con1,localhost,root,,)
--send
ALTER TABLE t FORCE, ALGORITHM=COPY;

--connection default
INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;

--connection con1
--reap
DROP TABLE t;
{code}

{noformat:title=bb-11.0-oalter e599b8b458}
Warning: Memory not freed: 96

=================================================================
==2695459==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
    #2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
    #3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
    #4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
    #5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
    #6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
    #7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
    #8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
    #9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
    #10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
    #11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
    #12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
    #13 0x5584f1391157 in Event_log::write_cache(THD*, st_io_cache*) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
    #14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
    #15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
    #16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
    #17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
    #18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
    #19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
    #20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
    #21 0x5584f076bd4c in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
    #22 0x5584f0741f44 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
    #23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
    #24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
    #25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
    #26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
    #27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442

SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
230329 0:36:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
read_buffer_size=131072
max_used_connections=2
thread_count=0
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x100000
sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385809 385809 processes
Max open files 1024 1024 files
Max locked memory 12649951232 12649951232 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385809 385809 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

Fatal signal 11 while backtracing
{noformat}

Not reproducible on the baseline.

The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough {{--repeat=N}}. *Also with {{--force-restart}}!*

{{REPEAT}} in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role {{JSON_TABLE}} plays, possibly the same.

{code:sql}
CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;
INSERT INTO t VALUES (NULL);

--connect (con1,localhost,root,,)
--send
  ALTER TABLE t FORCE, ALGORITHM=COPY;

--connection default
INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;

--connection con1
--reap
DROP TABLE t;
{code}

{noformat:title=bb-11.0-oalter e599b8b458}
Warning: Memory not freed: 96

=================================================================
==2695459==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
    #2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
    #3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
    #4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
    #5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
    #6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
    #7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
    #8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
    #9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
    #10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
    #11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
    #12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
    #13 0x5584f1391157 in Event_log::write_cache(THD*, st_io_cache*) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
    #14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
    #15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
    #16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
    #17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
    #18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
    #19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
    #20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
    #21 0x5584f076bd4c in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
    #22 0x5584f0741f44 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
    #23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
    #24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
    #25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
    #26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
    #27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442

SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
230329 0:36:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
read_buffer_size=131072
max_used_connections=2
thread_count=0
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x100000
sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385809 385809 processes
Max open files 1024 1024 files
Max locked memory 12649951232 12649951232 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385809 385809 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

Fatal signal 11 while backtracing
{noformat}

Not reproducible on the baseline.

Elena Stepanova made changes - 2023-03-28 21:46

Description

The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough {{--repeat=N}}. *Also with {{--force-restart}}!*

{{REPEAT}} in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role {{JSON_TABLE}} plays, possibly the same.

{code:sql}
CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;
INSERT INTO t VALUES (NULL);

--connect (con1,localhost,root,,)
--send
  ALTER TABLE t FORCE, ALGORITHM=COPY;

--connection default
INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;

--connection con1
--reap
DROP TABLE t;
{code}

{noformat:title=bb-11.0-oalter e599b8b458}
Warning: Memory not freed: 96

=================================================================
==2695459==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
    #2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
    #3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
    #4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
    #5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
    #6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
    #7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
    #8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
    #9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
    #10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
    #11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
    #12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
    #13 0x5584f1391157 in Event_log::write_cache(THD*, st_io_cache*) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
    #14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
    #15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
    #16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
    #17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
    #18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
    #19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
    #20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
    #21 0x5584f076bd4c in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
    #22 0x5584f0741f44 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
    #23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
    #24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
    #25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
    #26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
    #27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442

SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
230329 0:36:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
read_buffer_size=131072
max_used_connections=2
thread_count=0
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x100000
sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385809 385809 processes
Max open files 1024 1024 files
Max locked memory 12649951232 12649951232 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385809 385809 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

Fatal signal 11 while backtracing
{noformat}

Not reproducible on the baseline.

The test case is very non-deterministic. It currently fails for me fairly well, usually within ~10 attempts, but it is very volatile, so run with big enough {{--repeat=N}}. *Also with {{\-\-force-restart}}!*

{{REPEAT}} in the test case is not an important element of the scenario, it just helps with the timing. I'm not sure what role {{JSON_TABLE}} plays, possibly the same.

{code:sql}
CREATE TABLE t (f LONGBLOB DEFAULT NULL) ENGINE=MyISAM;
INSERT INTO t VALUES (NULL);

--connect (con1,localhost,root,,)
--send
  ALTER TABLE t FORCE, ALGORITHM=COPY;

--connection default
INSERT INTO t SELECT REPEAT('a',130000) FROM JSON_TABLE(CONCAT('[',REPEAT('"a",',1000),'"a"]'), '$' COLUMNS (col1 FOR ORDINALITY)) AS u;

--connection con1
--reap
DROP TABLE t;
{code}

{noformat:title=bb-11.0-oalter e599b8b458}
Warning: Memory not freed: 96

=================================================================
==2695459==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7fb4becb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x5584f23b5b6a in my_malloc /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:91
    #2 0x5584f23b6cfb in my_strdup /data/src/bb-11.0-oalter-asan/mysys/my_malloc.c:235
    #3 0x5584f23b8b32 in my_register_filename /data/src/bb-11.0-oalter-asan/mysys/my_open.c:140
    #4 0x5584f238eca8 in create_temp_file /data/src/bb-11.0-oalter-asan/mysys/mf_tempfile.c:128
    #5 0x5584f2356249 in real_open_cached_file /data/src/bb-11.0-oalter-asan/mysys/mf_cache.c:61
    #6 0x5584f2362b4d in my_b_flush_io_cache /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1706
    #7 0x5584f235ca73 in _my_b_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:559
    #8 0x5584f235820d in my_b_write /data/src/bb-11.0-oalter-asan/include/my_sys.h:545
    #9 0x5584f236237f in my_b_safe_write /data/src/bb-11.0-oalter-asan/mysys/mf_iocache.c:1623
    #10 0x5584f13e97ae in Log_event_writer::write_internal(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:766
    #11 0x5584f13eabbf in Log_event_writer::write_data(unsigned char const*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log_event_server.cc:869
    #12 0x5584f13b3897 in CacheWriter::write(unsigned char*, unsigned long) /data/src/bb-11.0-oalter-asan/sql/log.cc:7675
    #13 0x5584f1391157 in Event_log::write_cache(THD*, st_io_cache*) /data/src/bb-11.0-oalter-asan/sql/log.cc:7902
    #14 0x5584f138f857 in binlog_online_alter_end_trans /data/src/bb-11.0-oalter-asan/sql/log.cc:7711
    #15 0x5584f136d7d9 in binlog_commit(THD*, bool, bool) /data/src/bb-11.0-oalter-asan/sql/log.cc:2333
    #16 0x5584f1038b84 in commit_one_phase_2 /data/src/bb-11.0-oalter-asan/sql/handler.cc:2116
    #17 0x5584f10387e9 in ha_commit_one_phase(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:2078
    #18 0x5584f1036ab7 in ha_commit_trans(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/handler.cc:1872
    #19 0x5584f0c40b90 in trans_commit_stmt(THD*) /data/src/bb-11.0-oalter-asan/sql/transaction.cc:472
    #20 0x5584f075f608 in mysql_execute_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:6061
    #21 0x5584f076bd4c in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:8000
    #22 0x5584f0741f44 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1894
    #23 0x5584f073ec76 in do_command(THD*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_parse.cc:1407
    #24 0x5584f0bfd039 in do_handle_one_connection(CONNECT*, bool) /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1416
    #25 0x5584f0bfc9fa in handle_one_connection /data/src/bb-11.0-oalter-asan/sql/sql_connect.cc:1318
    #26 0x5584f17d8a37 in pfs_spawn_thread /data/src/bb-11.0-oalter-asan/storage/perfschema/pfs.cc:2201
    #27 0x7fb4be0a7fd3 in start_thread nptl/pthread_create.c:442

SUMMARY: AddressSanitizer: 96 byte(s) leaked in 1 allocation(s).
230329 0:36:08 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 11.0.1-MariaDB-debug-log source revision: e599b8b45867cd24720a9ecd4ba28500f579c5a4
read_buffer_size=131072
max_used_connections=2
thread_count=0
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x100000
sanitizer_common/sanitizer_common_interceptors.inc:4277(__interceptor_backtrace.part.0)[0x7fb4bec51f31]
mysys/stacktrace.c:215(my_print_stacktrace)[0x5584f23c6cd1]
sql/signal_handler.cc:238(handle_fatal_signal)[0x5584f1027e24]
libc_sigaction.c:0(__restore_rt)[0x7fb4be05af90]
nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fb4be0a9ccc]
posix/raise.c:27(__GI_raise)[0x7fb4be05aef2]
stdlib/abort.c:81(__GI_abort)[0x7fb4be045472]
sanitizer_common/sanitizer_posix_libcdep.cpp:137(__sanitizer::Abort())[0x7fb4becd650f]
sanitizer_common/sanitizer_termination.cpp:59(__sanitizer::Die())[0x7fb4bece2ba1]
lsan/lsan_common_linux.cpp:120(__lsan::HandleLeaks())[0x7fb4becea87c]
lsan/lsan_common.cpp:732(__lsan::DoLeakCheck())[0x7fb4bece8dc5]
stdlib/cxa_finalize.c:84(__cxa_finalize)[0x7fb4be05cf37]
crtstuff.c:0(__do_global_dtors_aux)[0x7fb4bec24bc7]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt8t/src/bb-11.0-oalter-asan/mysql-test/var/mysqld.1/data
Resource Limits:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385809 385809 processes
Max open files 1024 1024 files
Max locked memory 12649951232 12649951232 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385809 385809 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Core pattern: core

Fatal signal 11 while backtracing
{noformat}

Not reproducible on the baseline.

Nikita Malyavin made changes - 2023-03-31 20:09

Status

Open [ 1 ]

In Progress [ 3 ]

Elena Stepanova made changes - 2023-04-02 16:38

Link

This issue relates to ~~MDEV-28808~~ [ ~~MDEV-28808~~ ]

Nikita Malyavin made changes - 2023-04-03 20:40

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Nikita Malyavin made changes - 2023-04-17 18:13

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Nikita Malyavin made changes - 2023-04-18 12:08

Status

In Progress [ 3 ]

In Testing [ 10301 ]

Nikita Malyavin made changes - 2023-04-18 12:08

Status

In Testing [ 10301 ]

Stalled [ 10000 ]

Nikita Malyavin made changes - 2023-04-18 12:08

Status

Stalled [ 10000 ]

In Testing [ 10301 ]

Nikita Malyavin made changes - 2023-04-18 12:08

Status

In Testing [ 10301 ]

Stalled [ 10000 ]

Nikita Malyavin made changes - 2023-04-18 12:09

Assignee	Nikita Malyavin [ nikitamalyavin ]	Sergei Golubchik [ serg ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Sergei Golubchik made changes - 2023-05-02 18:26

Assignee	Sergei Golubchik [ serg ]	Nikita Malyavin [ nikitamalyavin ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Nikita Malyavin made changes - 2023-05-02 18:29

Status

Stalled [ 10000 ]

In Testing [ 10301 ]

Ralf Gebhardt made changes - 2023-05-30 08:18

Fix Version/s		11.2 [ 28603 ]
Fix Version/s	11.1 [ 28549 ]

Sergei Golubchik made changes - 2023-08-16 09:34

Fix Version/s		11.2.1 [ 29034 ]
Fix Version/s	11.2 [ 28603 ]
Resolution		Fixed [ 1 ]
Status	In Testing [ 10301 ]	Closed [ 6 ]

People

Assignee:: Nikita Malyavin

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2023-03-28 21:45

Updated:: 2023-08-16 09:34

Resolved:: 2023-08-16 09:34

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration