Bug #61516 Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
Submitted: 14 Jun 2011 17:54 Modified: 17 Mar 2015 14:06
Reporter: michael press Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.5.11 OS:Any (vista)
Assigned to: CPU Architecture:Any

[14 Jun 2011 17:54] michael press
Description:
Version: '5.5.11'  socket: ''  port: 3306  MySQL Community Server (GPL)
110614 18:23:38  InnoDB: Assertion failure in thread 6108 in file ..\..\..\mysql-5.5.11\storage\innobase\trx\trx0purge.c line 828
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.

How to repeat:
start the service
[14 Jun 2011 18:32] MySQL Verification Team
Thank you for the bug report. Could you please provide the *.err file?. Thanks.
[14 Jun 2011 22:18] michael press
ERR File

Attachment: Enzo-PC.zip (application/x-zip-compressed, text), 8.19 KiB.

[15 Jun 2011 16:08] Valeriy Kravchuk
Please, check Event Log in Windows for some error at the moment when this problem happened for the first time.

If you need to start your server and get your data back, looks like you should try to start with

innodb_force_recovery = 2

added to my.ini (send your my.ini, please). Check http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html for the details.
[15 Jul 2011 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[25 Sep 2013 1:02] Sameer Yami
We are seeing the same bug happening on mysql  Ver 14.14 Distrib 5.5.20, for Linux (i686).

Is there any update on this bug?
[25 Sep 2013 1:40] Sameer Yami
We were doing a fast shutdown of mysql. So is it possible that this bug can be avoided if a slow shutdown of mysql is done since a crash recovery will not happen in this case?
[14 May 2014 1:24] George Donev
I am having the same issue.

This is the error from the error log. I tried running the innodb_force_recovery = from 1 - 6 it did not help.

Error when trying to start mysql(from error log)
----
140514  3:18:52 [Note] Plugin 'FEDERATED' is disabled.
140514  3:18:52 InnoDB: The InnoDB memory heap is disabled
140514  3:18:52 InnoDB: Mutexes and rw_locks use Windows interlocked functions
140514  3:18:52 InnoDB: Compressed tables use zlib 1.2.3
140514  3:18:52 InnoDB: Initializing buffer pool, size = 16.0M
140514  3:18:52 InnoDB: Completed initialization of buffer pool
140514  3:18:52 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 32688618180
140514  3:18:52  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 32688647218
140514  3:18:53  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 41 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 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
140514  3:18:54  InnoDB: Waiting for the background threads to start
140514  3:18:55 InnoDB: 1.1.8 started; log sequence number 32688647218
140514  3:18:55 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
140514  3:18:55 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
140514  3:18:55 [Note] Server socket created on IP: '0.0.0.0'.
140514  3:18:55 [Note] Event Scheduler: Loaded 0 events
140514  3:18:55 [Note] E:\xampp\mysql\bin\mysqld.exe: ready for connections.
Version: '5.5.27'  socket: ''  port: 3306  MySQL Community Server (GPL)
140514  3:18:56  InnoDB: Assertion failure in thread 9388 in file trx0purge.c line 829
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
[25 Sep 2014 15:16] Marko Mäkelä
Posted by developer:
 
This could be a duplicate of Bug#11762661 aka
Bug#55283 assert trx0roll.c undo_no + 1 == trx->undo_no in trx_rollback_or_clean_all_recov
which might have been fixed in 5.7, but very likely not in 5.6 or earlier.
[22 Dec 2014 1:57] zhai weixiang
Hi, Marko. We encountered a similar crash on 5.6:
ut_a(purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no);

purge_sys->iter.trx_no = 13580
purge_sys->iter.trx_no = 13579

I've searched launchpad  but can't find the related revision No that fixed this bug. :(
[22 Dec 2014 1:58] zhai weixiang
purge_sys->iter.trx_no = 13580
purge_sys->rseg->last_trx_no = 13579
[3 Feb 2015 11:50] MySQL Verification Team
maybe related:
Bug 20445525 - ADD A CONSISTENCY CHECK AGAINST DB_TRX_ID BEING IN THE FUTURE 
http://bugs.mysql.com/bug.php?id=75697
http://forums.mysql.com/read.php?22,604726,604726
[24 Feb 2015 14:23] MySQL Verification Team
Small correction.

We are unable to repeat this bug for the reason that a test case is not fully reproducible.

Hence, what we need is a detailed and fully repeatable test case.
[12 Mar 2015 13:41] MySQL Verification Team
another occurrence:
http://bugs.mysql.com/bug.php?id=76282
[12 Mar 2015 14:10] MySQL Verification Team
Looks like there is another occurrence of this bug, but still without a test case.
[18 Mar 2015 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[18 Mar 2015 16:34] Andrii Nikitin
I assume that such problem may happen if ibdata1 is not in sync with logs and/or other ibd files.