MySQL Bugs: #61516: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx

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

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

Thank you for the bug report. Could you please provide the *.err file?. Thanks.

ERR File

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

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.

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".

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?

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?

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.

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.

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. :(

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

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

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.

another occurrence:
http://bugs.mysql.com/bug.php?id=76282

Looks like there is another occurrence of this bug, but still without a test case.

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".

I assume that such problem may happen if ibdata1 is not in sync with logs and/or other ibd files.