bug1535312 test failure

Bug #1544671 reported by Sergei Glushchenko on 2016-02-11
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

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]

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'

tags: added: qa57

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  Edit
Everyone can see this information.

Other bug subscribers