Public bug reported:
Hi
$ innobackupex --version
innobackupex version 2.4.1 Linux (x86_64) (revision id: a2dc9d4)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.6 (jessie)
Release: 8
Codename: jessie
I hit SIGSEGV when preparing a backup on a 5.7.10-3-log percona server:
$ innobackupex --use-memory=1G --apply-log <path...>
190801 22:41:05 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
/usr/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64)
(revision id: a2dc9d4)
xtrabackup: cd to /backup/mysql/20190801_223001
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=84606976,
start_lsn=(4248151318060)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = undo1:100M:autoextend:max:2000M
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 84606976
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = undo1:100M:autoextend:max:2000M
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 84606976
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory
parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.8
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size
= 100M
InnoDB: Completed initialization of buffer pool
InnoDB: If the mysqld execution user is authorized, page cleaner thread
priority can be changed. See the man page of setpriority().
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4248151318060
InnoDB: Doing recovery: scanned up to log sequence number 4248156495360 (6%)
InnoDB: Doing recovery: scanned up to log sequence number 4248161738240 (13%)
InnoDB: Doing recovery: scanned up to log sequence number 4248166981120 (20%)
InnoDB: Doing recovery: scanned up to log sequence number 4248172224000 (27%)
InnoDB: Doing recovery: scanned up to log sequence number 4248177466880 (34%)
InnoDB: Doing recovery: scanned up to log sequence number 4248182709760 (41%)
InnoDB: Doing recovery: scanned up to log sequence number 4248187952640 (48%)
InnoDB: Doing recovery: scanned up to log sequence number 4248193195520 (55%)
InnoDB: Doing recovery: scanned up to log sequence number 4248198438400 (62%)
InnoDB: Doing recovery: scanned up to log sequence number 4248203681280 (69%)
InnoDB: Doing recovery: scanned up to log sequence number 4248208924160 (76%)
InnoDB: Doing recovery: scanned up to log sequence number 4248214167040 (83%)
InnoDB: Doing recovery: scanned up to log sequence number 4248219409920 (90%)
InnoDB: Doing recovery: scanned up to log sequence number 4248224652800 (97%)
InnoDB: Doing recovery: scanned up to log sequence number 4248226533529 (100%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Doing recovery: scanned up to log sequence number 4248154660352 (4%)
InnoDB: Doing recovery: scanned up to log sequence number 4248159903232 (11%)
InnoDB: Doing recovery: scanned up to log sequence number 4248165146112 (18%)
InnoDB: Doing recovery: scanned up to log sequence number 4248170388992 (25%)
InnoDB: Doing recovery: scanned up to log sequence number 4248175631872 (32%)
InnoDB: Doing recovery: scanned up to log sequence number 4248180874752 (39%)
InnoDB: Doing recovery: scanned up to log sequence number 4248186117632 (46%)
InnoDB: Doing recovery: scanned up to log sequence number 4248191360512 (53%)
InnoDB: Doing recovery: scanned up to log sequence number 4248196603392 (60%)
InnoDB: Doing recovery: scanned up to log sequence number 4248201846272 (67%)
InnoDB: Doing recovery: scanned up to log sequence number 4248207089152 (74%)
InnoDB: Doing recovery: scanned up to log sequence number 4248212332032 (81%)
InnoDB: Doing recovery: scanned up to log sequence number 4248217574912 (88%)
InnoDB: Doing recovery: scanned up to log sequence number 4248222817792 (95%)
InnoDB: Doing recovery: scanned up to log sequence number 4248226533529 (100%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20 21 22 23
20:41:19 UTC - xtrabackup got signal 11 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
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 0x10000
/usr/bin/innobackupex(my_print_stacktrace+0x2c)[0xdf158c]
/usr/bin/innobackupex(handle_fatal_signal+0x261)[0x9c17d1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x697676a798d0]
/usr/bin/innobackupex(_Z24page_dir_find_owner_slotPKh+0x8a)[0x785b4a]
/usr/bin/innobackupex(_Z19page_cur_delete_recP10page_cur_tPK12dict_index_tPKmP5mtr_t+0x75)[0x7a16d5]
/usr/bin/innobackupex(_Z25page_cur_parse_delete_recPhS_P11buf_block_tP12dict_index_tP5mtr_t+0xa7)[0x7a1ee7]
/usr/bin/innobackupex[0x93378f]
/usr/bin/innobackupex(_Z22recv_recover_page_funcmP11buf_block_t+0xb8f)[0x934def]
/usr/bin/innobackupex(_Z20buf_page_io_completeP10buf_page_tb+0x58c)[0x7b5b2c]
/usr/bin/innobackupex(_Z12fil_aio_waitm+0x11f)[0x7f973f]
/usr/bin/innobackupex(io_handler_thread+0x28)[0x80a248]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x697676a720a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x697674e2662d]
Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
Happens randomly.
Do you need any more details ?
Thanks,
** Affects: percona-xtrabackup (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838766
Title:
xtrabackup got signal 11 - on _Z24page_dir_find_owner_slotPKh ->
libpthread.so.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/percona-xtrabackup/+bug/1838766/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
