MySQL Bugs: #4979: INNODB SHOW TABLES hangs causes a long semaphore wait

Bug #4979	INNODB SHOW TABLES hangs causes a long semaphore wait
Submitted:	10 Aug 2004 16:10	Modified:	30 Oct 2004 9:16
Reporter:	David Hammink	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	4.0.20-Max	OS:	Linux (Linux Redhat 9.0)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
After a client (Mysql-Front in this case ) does a SHOW TABLE STATUS FROM
it can occur that this command runs forever.

The Client is then stopped (illegally) the command stays there.
If I do not pay attention the mysql server will be reset due to "long semaphore wait"

The INNODB database is just recently setup. And still in a development stage. But currently not active at all (Basically I only use 1 table )
--Thread 1485810480 has waited at ../../innobase/trx/../include/trx0sys.ic line 101 for 626.00 seconds the semaphore:
X-lock on RW-latch at 0x5547a960 created in file buf0buf.c line 438
a writer (thread id 1485810480) has reserved it in mode wait exclusive
number of readers 1, waiters flag 1
Last time read locked in file buf0flu.c line 480
Last time write locked in file ../../innobase/trx/../include/trx0sys.ic line 101
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
040810 7:30:55InnoDB: Assertion failure in thread 1484798768 in file sync0arr.c line 925
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. See section 6.1 of
InnoDB: http://www.innodb.com/ibman.php about forcing recovery.
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=7
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x58803724, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80da864
0x400428f8
(nil)
0x4003d484
0x420df147
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contain

How to repeat:
Mysqlfront and then try to show the table status (not always mostly a couple of days after a reset)

Hi, David.  I can't repeat this with just the information you gave me; but I would very much like to find out what is happening.  Can you please try a few things for me, to help identify the problem?

First, can you turn on the general log?  Add this to your my.cnf:

[mysqld]
log

Or start mysqld_safe with the --log option.

After the server hangs, check the log file and see what exact commands mysql-front is using.  See if you can reproduce the hang without mysql-front (i.e., by using just the 'mysql' command line client, and typing in the exact same commands that mysql-front uses).

Can you try using our static binary, instead of the -max binary?  If you download our -standard version, you can just move your current mysqld to mysqld.save, and then copy the static binary into place, and restart the server.

Can you also please send the output of mysqldump --no-data your-db?  If the data are not too large, can you send them as well?  You may upload it to ftp.mysql.com:/pub/mysql/upload/bug4979.tar.gz; only MySQL developers have download access to those files.

Basically, I am trying to a) get a repeatable test case, and b) see if it might be related to system libraries on RH 9.0, or if it shows up with a statically linked binary as well.

Thank you very much for your bug report, and in advance I thank you for any extra information you can provide.

Regards,

Timothy

Hi!

Please send the FULL .err log to me! heikki.tuuri@innodb.com

Regards,

Heikki