xtrabackup got signal if --databases= very long
General
Escalation
General
Escalation
Description
Environment
[root@localhost test]# mysqld --version
/usr/local/mysql-8.0.35-linux-glibc2.12-x86_64/bin/mysqld Ver 8.0.35 for Linux on x86_64 (MySQL Community Server - GPL)
[root@localhost test]# xtrabackup --version
2024-12-03T15:55:30.917159+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --open_files_limit=762140 --innodb_max_dirty_pages_pct=40 --innodb_autoextend_increment=128 --innodb_file_per_table=1 --innodb_open_files=762140 --innodb_log_buffer_size=64M --innodb_read_io_threads=16 --innodb_write_io_threads=8 --innodb_flush_method=O_DIRECT --innodb_adaptive_hash_index=0
xtrabackup version 8.0.35-31 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 2b9a1f65)
Activity
Aaditya Dubey
January 1, 2025 at 1:19 PM
(edited)
Hi @jia liu
Thank you for the report.
Verified as described.
#Server Version
mysql [localhost:8039] {msandbox} ((none)) > select version();
+-----------+
| version() |
+-----------+
| 8.0.39-30 |
+-----------+
1 row in set (0.01 sec)
# Backup Version
./xtrabackup version 8.0.35-31 based on MySQL server 8.0.35 Linux (x86_64) (revision id: 2b9a1f65)
# Backup Command when database name having no spaces, it works fine.
./xtrabackup --defaults-file=/home/xxxx/sandboxes/msb_ps8_0_39/my.sandbox.cnf --backup --datxxxxr=/home/xxxx/sandboxes/msb_ps8_0_39/data --target-dir=/home/xxxx/backup --databases='test' --user=msandbox --password=msandbox --socket=/tmp/mysql_sandbox8039.sock --parallel=10 --innodb-log-buffer-size=64M --compress=zstd --compress-threads=10
...
2025-01-01T13:12:29.268522-00:00 0 [Note] [MY-011825] [Xtrabackup] completed OK!
# Backup Command when database name having multiple spaces, it crashes.
./xtrabackup --defaults-file=/home/xxxx/sandboxes/msb_ps8_0_39/my.sandbox.cnf --backup --datadir=/home/xxxx/sandboxes/msb_ps8_0_39/data --target-dir=/home/xxxx/backup --databases=' test' --user=msandbox --password=msandbox --socket=/tmp/mysql_sandbox8039.sock --parallel=10 --innodb-log-buffer-size=64M --compress=zstd --compress-threads=10
...
2025-01-01T13:12:47Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=
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 = 0 thread_stack 0x100000
./xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x555d97c6110d]
./xtrabackup(print_fatal_signal(int)+0x393) [0x555d9693fa83]
./xtrabackup(handle_fatal_signal+0xa5) [0x555d9693fb35]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7ff491c0d420]
./xtrabackup(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned long, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, unsigned long> > >::~map()+0x10) [0x555d963c02d0]
/lib/x86_64-linux-gnu/libc.so.6(+0x468a7) [0x7ff49115d8a7]
/lib/x86_64-linux-gnu/libc.so.6(on_exit+0) [0x7ff49115da60]
./xtrabackup(main+0x12a8) [0x555d96344af8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7ff49113b083]
./xtrabackup(_start+0x2a) [0x555d9637a81a]
Please report a bug at https://jira.percona.com/projects/PXB
Details
Details
Assignee
Unassigned
UnassignedReporter
jia liu
jia liuSecurity Level Help
None
Needs QA
Yes
Affects versions
Priority
Created December 3, 2024 at 7:57 AM
Updated January 1, 2025 at 1:22 PM
if a long --databases= is given, backup will fail with signal 11.
2024-12-03T07:25:28Z UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]= 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 = 0 thread_stack 0x100000 xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x2585c2d] xtrabackup(print_fatal_signal(int)+0x393) [0x12c48d3] xtrabackup(handle_fatal_signal+0x95) [0x12c49b5] /lib64/libpthread.so.0(+0xf630) [0x7f0597616630] /lib64/libc.so.6(_IO_vfprintf+0x4a79) [0x7f05951ef079] /lib64/libc.so.6(__vasprintf_chk+0xb5) [0x7f05952ba145] /lib64/libc.so.6(__asprintf_chk+0x82) [0x7f05952ba082] xtrabackup(get_xtrabackup_info(MYSQL*)+0x1a2) [0xd32a02] xtrabackup(write_xtrabackup_info(MYSQL*)+0x58) [0xd32bf8] xtrabackup(backup_finish(Backup_context&)+0x1c2) [0xd52d62] xtrabackup(xtrabackup_backup_func()+0x1ce6) [0xd1a9d6] xtrabackup(main+0x1ade) [0xcc72de] /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f05951c4555] xtrabackup() [0xcfd155]
the command is
rm -rf /tmp/test mkdir -p /tmp/test xtrabackup --backup --safe-slave-backup --host=127.0.0.1 --port=3306 --user=dbbackup --password=******** --databases=' db01.t1' --parallel=10 --innodb-log-buffer-size=64M --compress=zstd --compress-threads=10 --target-dir='/tmp/test' > '/tmp/test/test.log' 2>&1 tail -n 30 /tmp/test/test.log
when there is 1859 white space before db01.t1, it will fail.
when there is 1858 or less white space before db01.t1, it will success.
due to different username and password and table name, the number of white space needed to reproduce the bug might be varies. but a long enough --databases will reproduce the fail.