Wayne,
the bug found and fixed.
If SHOW INNODB STATUS or innodb_monitor printed several hundred
transactions, and the output was truncated, it forgot to release the
'kernel' mutex, causing the hang.
Also the main thread was hung. That is why it claimed to be doing a
background table drop.
The bug will be fixed in 3.23.53 and 4.0.5. Until then do not use SHOW
INNODB STATUS, innodb_monitor, or innodb_lock_monitor if you have hundreds
of concurrent connections to the server.
Thank you for the detailed bug report,
Heikki
Innobase Oy
ChangeSet
1.1208 02/10/03 23:07:32 [EMAIL PROTECTED] +1 -0
lock0lock.c:
Fix bug: if SHOW INNODB STATUS or innodb_monitor printed several hundred
transactions, the output was truncated and we forgot to release the kernel
mutex
innobase/lock/lock0lock.c
1.17 02/10/03 23:07:18 [EMAIL PROTECTED] +20 -0
Fix bug: if SHOW INNODB STATUS or innodb_monitor printed several hundred
transactions, the output was truncated and we forgot to release the kernel
mutex
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: heikki
# Host: hundin.mysql.fi
# Root: /home/heikki/mysql
--- 1.16/innobase/lock/lock0lock.c Tue Oct 1 13:47:39 2002
+++ 1.17/innobase/lock/lock0lock.c Thu Oct 3 23:07:18 2002
@@ -3599,6 +3599,8 @@
mtr_t mtr;
if (buf_end - buf < 600) {
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3623,6 +3625,9 @@
if ((ulint)(buf_end - buf)
< 100 + strlen(lock_latest_err_buf)) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3630,6 +3635,9 @@
}
if (buf_end - buf < 600) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3641,6 +3649,9 @@
while (trx) {
if (buf_end - buf < 900) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3678,6 +3689,9 @@
}
if (buf_end - buf < 900) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3688,6 +3702,9 @@
buf += strlen(buf);
if (buf_end - buf < 500) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
@@ -3742,6 +3759,9 @@
}
if (buf_end - buf < 500) {
+ lock_mutex_exit_kernel();
+ sprintf(buf, "... output truncated!\n");
+
return;
}
----- Original Message -----
From: "Heikki Tuuri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 03, 2002 9:09 PM
Subject: Re: InnoDB hard lockup
> Wayne,
>
> please send me the whole MySQL error log.
>
> Looks like some thread, which had reserved the InnoDB 'kernel' mutex to
> access the InnoDB lock table, got stuck.
>
> This is interesting:
>
> "
> 5 queries inside InnoDB, 0 queries in queue; main thread: doing background
> drop tables
> "
>
> If you drop a table where there still are queries running, then InnoDB
> delays the drop table until the queries have ended, and only after that
> drops the table. When dropping the table, InnoDB has to remove also any
> locks there are on the table. The code is not that well tested. The bug
> might be there.
>
> What DROP TABLE and what queries could have been involved?
>
> Do you have very many tables?
>
> Does SHOW TABLE STATUS take long?
>
> Are you sure you ran innodb_monitor and not innodb_lock_monitor?
>
> Can you repeat the bug?
>
> Best regards,
>
> Heikki Tuuri
> Innobase Oy
> ---
> Order technical MySQL/InnoDB support at https://order.mysql.com/
> See http://www.innodb.com for the online manual and latest news on InnoDB
>
>
>
> Copied message:
> ..............
> Subject: InnoDB hard lockup
> From: Wayne Lewis
> Date: Thu, 3 Oct 2002 08:48:26 -0700
>
>
> --------------------------------------------------------------------------
--
> ----
>
> Hi All,
>
> First thanks to all who worked on InnoDB, it is truely exciting to get its
> features in an open-source DB. We've had an excellent experience thus far
> with a few exceptions. Any help on solving the problem below is greatly
> appreciated ...
>
> We experienced a hard lockup a few days ago with mysql-max-3.23.52 for
> Solaris 2.7. The DB had been running very well for over a month until the
> innodb_monitor was turned on. After turning it on, all InnoDB threads
> blocked within a few minutes, and we saw the messages below in the error
> log.
>
> The only other info that may seem relevent is that we have a monitor that
> executes "show table status" every 15 minutes to check for remaining space
> in the InnoDB tablespace. That monitor does not run in our test
environment
> and we never had a problem with the innodb monitor in our test environment
> while executing a similar workload. So this problem may be correlated or
> caused by the "show table status" command in conjunction with the innodb
> monitor.
>
> Any thoughts?
>
>
>
>
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
