assert for FK processing in client connection

Bug #1342959 reported by Seppo Jaakola on 2014-07-16
This bug affects 4 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Status tracked in 5.6
Seppo Jaakola
Percona XtraDB Cluster moved to
Status tracked in 5.6
Fix Released

Bug Description

Following assert was thrown for a client session:

2014-07-11 14:08:25 7f3cf55d8700 InnoDB: Assertion failure in thread 139899791312640 in file line 442
InnoDB: Failing assertion: foreign->referenced_table ->n_foreign_key_checks_running > 0

InnoDB: We intentionally generate a memory trap.
IInnoDB: Submit a detailed bug report to
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: about forcing recovery.
12:08:25 UTC - mysqld got signal 6 ;


stack_bottom = 7f3cf55d7d38 thread_stack 0x40000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f279400bd60): is an invalid pointer
Connection ID (thread ID): 31

Seppo Jaakola (seppo-jaakola) wrote :

This shows a potential race condition for foreign_table->n_foreign_key_checks_running when using a build made with option HAVE_ATOMIC_BUILTINS

Changed in codership-mysql:
importance: Undecided → Medium
status: New → In Progress
assignee: nobody → Seppo Jaakola (seppo-jaakola)
milestone: none → 5.6.19-25.6
Seppo Jaakola (seppo-jaakola) wrote :

a fix was pushed to remove the race for n_foreign_key_checks_running variable, in revision:

Przemek (pmalkowski) on 2014-07-23
tags: added: i38269

Percona now uses JIRA for bug reports so this bug report is migrated to:

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

Duplicates of this bug

Other bug subscribers