Bug #25494 LATEST DEADLOCK INFORMATION is not always cleared

Submitted: 9 Jan 2007 14:23 Modified: 20 Jun 2010 0:45
Reporter: Marko Mäkelä Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:4.0, 4.1, 5.0, 5.1 OS:Any
Assigned to: Marko Mäkelä CPU Architecture:Any

[9 Jan 2007 14:23] Marko Mäkelä
Description:
When the maximum search depth or cost is reached in lock_deadlock_recursive(), the error message buffer should be cleared. Whenever a different type of a deadlock is detected, the error message buffer is cleared. This is probably why this has not been noticed before.

It looks like this bug existed even before this change:

http://mysql.bkbits.net:8080/mysql-4.0/innobase/lock/lock0lock.c?PAGE=diffs&REV=1.31

In earlier versions of MySQL (4.0.18 or earlier), this would even lead to an assertion failure if the message buffer grew larger than 4000 bytes.

This was originally reported at:
http://forums.mysql.com/read.php?22,132387,132387

How to repeat:
Trigger the cutoff condition in lock_deadlock_recursive() multiple times in succession. Observe a long list of "*** WE ROLL BACK TRANSACTION (2)" in the output.

Suggested fix:
Add rewind(lock_latest_err_file)] before the first return(LOCK_VICTIM_IS_START) in lock_deadlock_recursive().
[16 Feb 2007 14:39] Heikki Tuuri
Patch over 5.0

Attachment: patch-5.0-lock0lock.c-bug25494 (text/plain), 1.47 KiB.

[16 Feb 2007 14:39] Heikki Tuuri
Marko,

I have attached a patch, but have not tested it.

The idea of the patch is to treat a deep/long search as if it were a genuine deadlock.

Regards,

Heikki
[6 Apr 2007 17:21] Bugs System
Pushed into 5.0.40
[6 Apr 2007 17:24] Bugs System
Pushed into 5.1.18-beta
[13 Apr 2007 18:00] Paul DuBois
Noted in 5.0.40, 5.1.18 changelogs.

For SHOW ENGINE INNODB STATUS, the LATEST DEADLOCK INFORMATION was
not always cleared properly.
[5 May 2010 15:23] Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 2:53] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[28 May 2010 5:51] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:21] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 6:49] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 May 2010 22:56] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[17 Jun 2010 11:52] Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 12:30] Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:18] Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.043 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.