Bug #1257266 “InnoDB: Failing assertion: sym_node->table != NULL...” : Bugs : Percona Server moved to https://jira.percona.com/projects/PS

Revision history for this message

Ovais Tariq (ovais-tariq) wrote on 2013-12-03:

#1

gdb_std.txt Edit (21.1 KiB, text/plain)

Revision history for this message

Ovais Tariq (ovais-tariq) wrote on 2013-12-03:

#2

gdb_full.txt Edit (65.5 KiB, text/plain)

Revision history for this message

George Ormond Lorch III (gl-az) wrote on 2013-12-04:

#3

I also see this no when testing XB 2.2 single binary against Percona Server 5.1 during prepare phase.

Revision history for this message

George Ormond Lorch III (gl-az) wrote on 2013-12-04:

#4

thread apply all bt xb 2.2 Edit (12.3 KiB, text/plain)

Here is the same/similar thread apply all bt from the single binary 2.2 xtrabackup. This is preparing a backup taken from upstream 5.5.

Revision history for this message

Ovais Tariq (ovais-tariq) wrote on 2013-12-06:

#5

@George,
So this affects 5.5 as well or was the backup being prepared for 5.6 server?

Revision history for this message

George Ormond Lorch III (gl-az) wrote on 2013-12-06:

#6

Ovais, the source/target server really isn't of consequence here. This occurred during the XB 2.2 prepare phase which uses the mini-embedded InnoDB code compiled into xtrabackup which is now supposed to be version agnostic. I _believe_ this mini-InnoDB code is based on the PS 5.6 XtraDB code but I am not certain at all about that. The only real useful data point that I had to offer here is that I am able to easily reproduce the same assertion with a very similar call stack by simply preparing a backup taken from a server under RQG load. From the call stacks, a quick guess is that InnoDB crash recovery now has some issue if a crash occurs at some sensitive point during a DDL (DROP TABLE specifically) operation.

Revision history for this message

Valerii Kravchuk (valerii-kravchuk) wrote on 2014-03-07:

#7

See also http://bugs.mysql.com/bug.php?id=68987 (does not mention xtrabackup or Precona Server at all)

Other reports of the same assertion are related to InnoDB table with fulltext index (see http://bugs.mysql.com/bug.php?id=71649)

tags:

added: upstream

Valerii Kravchuk (valerii-kravchuk) on 2014-07-11

tags:

added: i43717

markus_albe (markus-albe) on 2014-10-24

tags:

added: i47197

Revision history for this message

markus_albe (markus-albe) wrote on 2014-10-24:

#8

For 47197 it seems it could be related to open temporary tables on the slave at the time of backup (was running without --safe-slave-backup).

Revision history for this message

Peiran Song (peiran-song) wrote on 2014-11-27:

#9

Another customer (#48390) hit the same assertion failure during the prepare step of xtrabackup restore. It is reproducible on a dev server while backups from production server of the same server version haven't encountered this problem.

Source server : PS 5.5.36-34.2-648.precise-log (Ubuntu)
Xtrabackup on the source server: version 2.2.5 based on MySQL server 5.6.21 Linux (x86_64)
Xtrabackup on the destination server: version 2.2.6 based on MySQL server 5.6.21 Linux (x86_64)

I didn't reproduce the error when tested with backups taken while DROP TABLE was running on small tables using the same server and xtrabackup version.

tags:

added: i48390

Revision history for this message

Roel Van de Paar (roel11) wrote on 2014-12-01:

#10

As far as "InnoDB: Failing assertion: sym_node->table != NULL" is concerned, see also bug 1383062 and bug 1368846

Revision history for this message

Alexey Kopytov (akopytov) wrote on 2014-12-05:

#11

See also PXB bug #1399471 (which is likely a duplicate of bug #1383062).

Kenny Gryp (gryp) on 2015-01-13

tags:

added: i45163

Revision history for this message

George Ormond Lorch III (gl-az) wrote on 2015-03-27:

#12

Can't reproduce on any current release or not enough info to reproduce.

Revision history for this message

Steve Wechsler (steven-wechsler) wrote on 2015-04-24:

#13

Download full text (9.6 KiB)

Just received this error with:

xtrabackup version 2.2.9 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
MySQL version 5.5.27-percona-log (both source and target)

Backup command was:

$ innobackupex --socket=/opt/mysql/instance/live-arccms-01/admin/var/mysql.sock --user=dba_admin --password=mypass --defaults-file=/opt/mysql/instance/live-arccms-01/admin/conf/my.cnf --no-timestamp --stream=tar /opt/dba/local

Apply log command was:

$ innobackupex --apply-log /opt/mysql/instance/rep01-arccms-01/db/data

Log follows:

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

Get the latest version of Percona XtraBackup, documentation, and help resources:
http://www.percona.com/xb/p

150423 20:40:51 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!".

150423 20:40:51 innobackupex: Starting ibbackup with command: xtrabackup --defaults-file="/opt/mysql/instance/rep01-arccms-01/db/data/backup-my.cnf"
-defaults-group="mysqld" --prepare --target-dir=/opt/mysql/instance/rep01-arccms-01/db/data

xtrabackup version 2.2.9 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
xtrabackup: cd to /opt/mysql/instance/rep01-arccms-01/db/data
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=45572571136, start_lsn=(188057949968766)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata_01.idb:1G:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 45572571136
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata_01.idb:1G:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 45572571136
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 188057949968766
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 188057955211264 (0%)

[...]

In...

Just received this error with:

xtrabackup version 2.2.9 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
MySQL  version 5.5.27-percona-log (both source and target)

Backup command was:

$ innobackupex --socket=/opt/mysql/instance/live-arccms-01/admin/var/mysql.sock --user=dba_admin --password=mypass --defaults-file=/opt/mysql/instance/live-arccms-01/admin/conf/my.cnf --no-timestamp --stream=tar /opt/dba/local

Apply log command was:

$ innobackupex --apply-log /opt/mysql/instance/rep01-arccms-01/db/data

Log follows:

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

Get the latest version of Percona XtraBackup, documentation, and help resources:
http://www.percona.com/xb/p

150423 20:40:51  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!".

150423 20:40:51  innobackupex: Starting ibbackup with command: xtrabackup  --defaults-file="/opt/mysql/instance/rep01-arccms-01/db/data/backup-my.cnf"
-defaults-group="mysqld" --prepare --target-dir=/opt/mysql/instance/rep01-arccms-01/db/data

xtrabackup version 2.2.9 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
xtrabackup: cd to /opt/mysql/instance/rep01-arccms-01/db/data
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=45572571136, start_lsn=(188057949968766)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata_01.idb:1G:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 45572571136
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata_01.idb:1G:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 45572571136
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 188057949968766
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 188057955211264 (0%)

[...]

InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 188098430244864 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098435487744 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098440730624 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098445973504 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098451216384 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098456459264 (99%)
InnoDB: Doing recovery: scanned up to log sequence number 188098458918317 (99%)
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 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 1 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 8889 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 1345543452, file name /opt/mysql/instance/live-arccms-01/db/binlog/binlog.149353
InnoDB: Table tmp/#sql1392_2e3_0 in the InnoDB data dictionary has tablespace id 4560605, but tablespace with that id or name does not exist. ave you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticall removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table tmp/#sql297b_36b_0 in the InnoDB data dictionary has tablespace id 4560705, but tablespace with that id or name does not exist. ave you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticall removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table tmp/#sql3876_295_0 in the InnoDB data dictionary has tablespace id 4560792, but tablespace with that id or name does not exist. ave you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticall removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table tmp/#sql4ffb_583de_0 in the InnoDB data dictionary has tablespace id 4560288, but tablespace with that id or name does not exist Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticaly removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table tmp/#sql6df1_367_0 in the InnoDB data dictionary has tablespace id 4560423, but tablespace with that id or name does not exist. ave you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticall removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
InnoDB: Table tmp/#sql7f0f_2a9_0 in the InnoDB data dictionary has tablespace id 4560512, but tablespace with that id or name does not exist. ave you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automaticall removed, but the table still exists in the InnoDB internal data dictionary.
InnoDB: It will be removed from the data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
2015-04-23 22:32:10 2b84c738e9d0  InnoDB: Assertion failure in thread 47849278073296 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:32:10 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
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.

Thread pointer: 0x1f746eb0
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
xtrabackup(my_print_stacktrace+0x32) [0xa40e85]
xtrabackup(handle_fatal_signal+0x335) [0x9158d9]
/lib64/libpthread.so.0 [0x2b84c57c3ca0]
/lib64/libc.so.6(gsignal+0x35) [0x2b84c7063fc5]
/lib64/libc.so.6(abort+0x110) [0x2b84c7065a70]
xtrabackup [0xaa5a41]
xtrabackup(pars_update_statement(upd_node_t*, sym_node_t*, void*)+0x2c) [0xaa66b8]
xtrabackup(yyparse()+0xc18) [0xbcb6de]
xtrabackup(pars_sql(pars_info_t*, char const*)+0xc2) [0xaa41ec]
xtrabackup(que_eval_sql(pars_info_t*, char const*, unsigned long, trx_t*)+0x7f) [0x70718d]
xtrabackup(row_drop_table_for_mysql(char const*, trx_t*, bool, bool)+0xaaf) [0x6be0cb]
xtrabackup(row_mysql_drop_temp_tables()+0x213) [0x6befb1]
xtrabackup(recv_recovery_rollback_active()+0x2c) [0x6d6918]
xtrabackup(innobase_start_or_create_for_mysql()+0x17e3) [0x79a947]
xtrabackup [0x5db451]
xtrabackup [0x5e0746]
xtrabackup(main+0x962) [0x5e306a]
/lib64/libc.so.6(__libc_start_main+0xf4) [0x2b84c70519f4]
xtrabackup(__gxx_personality_v0+0x389) [0x5d65d9]

Revision history for this message

mig5 (mig5) wrote on 2018-01-10:

#14

I reproduce this in 5.6.38-83.0-1.jessie by simply altering a table (adding a column)

ALTER TABLE `sales_order_grid` ADD COLUMN `bold_order_comment` text NULL COMMENT 'Bold Order Comment'...

25 seconds into altering this table (it has lots of data) suddenly MySQL crashes with:

2018-01-09 20:28:26 7f1b97fff700 InnoDB: Assertion failure in thread 139756490979072 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
04:28:26 UTC - 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.
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.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=7
max_threads=153
thread_count=6
connection_count=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77253 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

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 0x80000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x8c5c6c]
/usr/sbin/mysqld(handle_fatal_signal+0x469)[0x64c599]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f1bfe0a9890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1bfc02f067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f1bfc030448]
/usr/sbin/mysqld[0x9ef737]
/usr/sbin/mysqld(_Z7yyparsev+0x131b)[0xb2cecb]
/usr/sbin/mysqld[0x9f0dff]
/usr/sbin/mysqld[0xb29653]
/usr/sbin/mysqld[0xb154a2]
/usr/sbin/mysqld[0xb16106]
/usr/sbin/mysqld(_Z23fts_optimize_sync_tablem+0x45)[0xb21765]
/usr/sbin/mysqld[0xb21ba8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064)[0x7f1bfe0a2064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1bfc0e262d]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

I reproduce this in 5.6.38-83.0-1.jessie by simply altering a table (adding a column)

ALTER TABLE `sales_order_grid` ADD COLUMN `bold_order_comment` text NULL COMMENT 'Bold Order Comment'...

25 seconds into altering this table (it has lots of data) suddenly MySQL crashes with:

2018-01-09 20:28:26 7f1b97fff700  InnoDB: Assertion failure in thread 139756490979072 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
04:28:26 UTC - 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.
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.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=7
max_threads=153
thread_count=6
connection_count=6
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77253 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

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 0x80000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x8c5c6c]
/usr/sbin/mysqld(handle_fatal_signal+0x469)[0x64c599]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f1bfe0a9890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1bfc02f067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f1bfc030448]
/usr/sbin/mysqld[0x9ef737]
/usr/sbin/mysqld(_Z7yyparsev+0x131b)[0xb2cecb]
/usr/sbin/mysqld[0x9f0dff]
/usr/sbin/mysqld[0xb29653]
/usr/sbin/mysqld[0xb154a2]
/usr/sbin/mysqld[0xb16106]
/usr/sbin/mysqld(_Z23fts_optimize_sync_tablem+0x45)[0xb21765]
/usr/sbin/mysqld[0xb21ba8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064)[0x7f1bfe0a2064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1bfc0e262d]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

Revision history for this message

Shahriyar Rzayev (rzayev-sehriyar) wrote on 2018-01-25:

#15

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

	Status	Importance	Assigned to
MySQL Server	Unknown	Unknown	mysql-bugs #69274
Percona Server moved to https://jira.percona.com/projects/PS	Invalid	High	Unassigned
5.6	Invalid	High	Unassigned

Percona Server moved to https://jira.percona.com/projects/PS

InnoDB: Failing assertion: sym_node->table != NULL

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches