MySQL Bugs: #23506: Tables over ten meg disappearing

Bug #23506	Tables over ten meg disappearing
Submitted:	20 Oct 2006 15:26	Modified:	27 Dec 2006 14:09
Reporter:	Robert Boone	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.24	OS:	Linux (RHEL 4)
Assigned to:		CPU Architecture:	Any

Description:
Several of our users are having this problem. Here is the log right after this happend to him:

061019 17:21:15 [Warning] Could not remove tmp table:
'./sg445_mychat2/mychat_c_messages', error: 2
061019 17:21:15 [Warning] Could not remove tmp table:
'./sg445_mychat2/mychat_c_messages', error: 2
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=110
max_connections=500
threads_connected=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
1096188 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0xadd3f950
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=0xadae3a4c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815e2a6
0x8b4898
0xfad567b0
0x815447c
0x815de34
0x817d202
0x8ae371
0x7d6ffe
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read
http://dev.mysql.com/doc/mysql/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
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=357234
The manual page at
http://www.mysql.com/doc/en/Crashing.html
contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
061019 17:21:16 mysqld restarted
061019 17:21:16 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...
061019 17:21:27 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 132070186.
InnoDB: Doing recovery: scanned up to log sequence number 0 132070186
061019 17:21:27 InnoDB: Started; log sequence number 0 132070186
061019 17:21:27 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.24-standard' socket: '/var/lib/mysql/mysql.sock' port: 3306
MySQL Community Edition - Standard (GPL)

How to repeat:
Not sure yet. All users that have this report it as random. The only consistency seems to be tables larger than ten meg and in application that get heavy use.

Thank you for a problem report. Please, send your my.cnf content and describe hardware used. Try to repeat with a newer version, 5.0.26, and inform about the results.

I have requested the my.cnf

my.cnf:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
#skip-innodb
max_user_connections=300
max_connections=500
query_cache_type=1
query_cache_limit=1M
query-cache-size=40M
max_allowed_packet=16M
interactive_timeout=100
wait_timeout=15
connect_timeout=10
    
[mysql.server]
user=mysql
#basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Hardware used:

Intel Dual Xeon 3.2Ghz / 4Gb / SATA drives

and

Intel Woodcrest 5130 Dual processor Dual Core / 8Gb / SA-SCSI drives

The resolved stack trace:

0x815e2a6
0x8b4898
0xfad567b0
0x815447c
0x815de34
0x817d202
0x8ae371		    
0x7d6ffe

the results of:

df -k

and any ideas on how to repeat are really needed. Please, try to use latest GA version, 5.0.27, also.

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