Percona XtraBackup moved to https://jira.percona.com/projects/PXB

bug1535312 test failure

Bug #1544671 reported by Sergei Glushchenko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Status tracked in 2.4
2.4
Fix Released
High
Sergei Glushchenko
Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.4.1

Bug Description

Test case fails sometimes with SEGV and following stack trace

17:17:32 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
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(my_print_stacktrace+0x2c)[0xc180fc]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(handle_fatal_signal+0x262)[0xb2efe2]
/lib64/libpthread.so.0(+0xf130)[0x7ffff7bce130]
/lib64/libc.so.6(_IO_vfprintf+0x1564)[0x7ffff6146a94]
/lib64/libc.so.6(+0x4c7e1)[0x7ffff614a7e1]
/lib64/libc.so.6(_IO_vfprintf+0x1ee)[0x7ffff614571e]
/lib64/libc.so.6(_IO_fprintf+0x87)[0x7ffff614fb77]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_Z22fil_path_to_space_namePKc+0x92)[0x83b432]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_ZN8Datafile8set_nameEPKc+0x147)[0x7417b7]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_ZN8Datafile21validate_for_recoveryEv+0x29a)[0x745a9a]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_Z12fil_ibd_loadmPKcRP11fil_space_t+0x311)[0x83f771]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x8cd72a]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x8ce828]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x8d3c04]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x8d4cef]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_Z35recv_recovery_from_checkpoint_startm+0xc2d)[0x8d5c3d]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(_Z34innobase_start_or_create_for_mysqlv+0x3641)[0x794b71]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x6e2166]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup(main+0xda3)[0x6f2813]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff611faf5]
/data/pxb/storage/innobase/xtrabackup/src/xtrabackup[0x70bb85]

Tags: qa57
Revision history for this message
Sergei Glushchenko (sergei.glushchenko) wrote :

Once datafile is opened by Datafile::validate_for_recovery it then is trying to set the name.
Datafile::set_name in turn behave different depending on the type of the tablespace.
For file-per-table tablespaces it will invoke fil_path_to_space_name which expect filepath to look like ./dbname/table_name.ibd. The issue is that Datafile::set_name makes decision whether tablespace is file-per-table or genral depending on FSP flags stored on first page. During the recovery FSP flags could sometimes be unitialized. In this case fil_path_to_space_name will crash trying to parse file path which looks like './datafile.ibd'

Revision history for this message
Sergei Glushchenko (sergei.glushchenko) wrote :

https://github.com/percona/percona-xtrabackup/pull/166

Shahriyar Rzayev (rzayev-sehriyar)
tags: added: qa57
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1368

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.