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ä
• Status: Closed
• 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:[e-mail]-20100505145753-ivlt4hclbrjy8eye) (version source revid:[e-mail]-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:[e-mail]-20100524190136-egaq7e8zgkwb9aqi) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (pib:16)

[28 May 2010 6:21] Bugs System

Pushed into 6.0.14-alpha (revid:[e-mail]-20100524190941-nuudpx60if25wsvx) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

[28 May 2010 6:49] Bugs System

Pushed into 5.5.5-m3 (revid:[e-mail]-20100524185725-c8k5q7v60i5nix3t) (version source revid:[e-mail]-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:[e-mail]-20100617114014-bva0dy24yyd67697) (version source revid:[e-mail]-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:[e-mail]-20100617115448-idrbic6gbki37h1c) (version source revid:[e-mail]-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:[e-mail]-20100617114611-61aqbb52j752y116) (version source revid:[e-mail]-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)