[debian-mysql] Bug#410821: maybe same bug with some detailed info in log

Mon Feb 25 10:58:13 UTC 2008

Hi everyone,

Yesterday one of our mysql servers (mysq-server-5.0.32-7etch1 on debian 
4.0 AMD64) has crashed with this messages:

Feb 24 18:19:50 vs1 mysqld[3665]: 080224 18:19:50 [ERROR] 
/usr/sbin/mysqld: Incorrect key file for table '/tmp/#sql_e50_9.MYI'; 
try to repair it
Feb 24 18:19:50 vs1 mysqld[3665]: 080224 18:19:50 [ERROR] 
/usr/sbin/mysqld: Incorrect key file for table '/tmp/#sql_e50_18.MYI'; 
try to repair it
Feb 24 18:19:50 vs1 mysqld[3665]: 080224 18:19:50 [ERROR] 
/usr/sbin/mysqld: Incorrect key file for table '/tmp/#sql_e50_15.MYI'; 
try to repair it
Feb 24 18:19:50 vs1 mysqld[3665]: 080224 18:19:50 [ERROR] 
/usr/sbin/mysqld: Incorrect key file for table '/tmp/#sql_e50_21.MYI'; 
try to repair it
Feb 24 18:19:50 vs1 mysqld[3665]: *** glibc detected *** double free or 
corruption (!prev): 0x000000000a364800 ***
Feb 24 18:19:50 vs1 mysqld[3665]: mysqld got signal 6;
Feb 24 18:19:50 vs1 mysqld[3665]: This could be because you hit a bug. 
It is also possible that this binary
Feb 24 18:19:50 vs1 mysqld[3665]: or one of the libraries it was linked 
against is corrupt, improperly built,
Feb 24 18:19:50 vs1 mysqld[3665]: or misconfigured. This error can also 
be caused by malfunctioning hardware.
Feb 24 18:19:50 vs1 mysqld[3665]: We will try our best to scrape up some 
info that will hopefully help diagnose
Feb 24 18:19:50 vs1 mysqld[3665]: the problem, but since we have already 
crashed, something is definitely wrong
Feb 24 18:19:50 vs1 mysqld[3665]: and this may fail.
Feb 24 18:19:50 vs1 mysqld[3665]:
Feb 24 18:19:50 vs1 mysqld[3665]: key_buffer_size=268435456
Feb 24 18:19:50 vs1 mysqld[3665]: read_buffer_size=131072
Feb 24 18:19:50 vs1 mysqld[3665]: max_used_connections=479
Feb 24 18:19:50 vs1 mysqld[3665]: max_connections=2048
Feb 24 18:19:50 vs1 mysqld[3665]: threads_connected=60
Feb 24 18:19:50 vs1 mysqld[3665]: It is possible that mysqld could use up to
Feb 24 18:19:50 vs1 mysqld[3665]: key_buffer_size + (read_buffer_size + 
sort_buffer_size)*max_connections = 268959728 K
Feb 24 18:19:50 vs1 mysqld[3665]: bytes of memory
Feb 24 18:19:50 vs1 mysqld[3665]: Hope that's ok; if not, decrease some 
variables in the equation.
Feb 24 18:19:50 vs1 mysqld[3665]:
Feb 24 18:19:50 vs1 mysqld[3665]: thd=0x2aaaaab5e800
Feb 24 18:19:50 vs1 mysqld[3665]: Attempting backtrace. You can use the 
following information to find out
Feb 24 18:19:50 vs1 mysqld[3665]: where mysqld died. If you see no 
messages after this, something went
Feb 24 18:19:50 vs1 mysqld[3665]: terribly wrong...
Feb 24 18:19:50 vs1 mysqld[3665]: Cannot determine thread, 
fp=0x45b52190, backtrace may not be correct.
Feb 24 18:19:50 vs1 mysqld[3665]: Bogus stack limit or frame pointer, 
fp=0x45b52190, stack_bottom=0x45b50000, thread_stack=1048576, aborting 
backtrace.
Feb 24 18:19:50 vs1 mysqld[3665]: Trying to get some variables.
Feb 24 18:19:50 vs1 mysqld[3665]: Some pointers may be invalid and cause 
the dump to abort...
Feb 24 18:19:50 vs1 mysqld[3665]: thd->query at 0xa2da7f0 = SELECT 
p.`id`, t.`title`, IFNULL(p.`modified`, p.`created`) AS `timestamp`,
Feb 24 18:19:50 vs1 mysqld[3665]:   CONCAT_WS('/', f.`filename`, 
CONCAT_WS('-', s.`filename`, FLOOR(COUNT(DISTINCT atp.`thread`) / 20)),
Feb 24 18:19:50 vs1 mysqld[3665]:     CONCAT_WS('-', 
FLOOR((COUNT(DISTINCT ap.`id`) - 1) / 20), t.`filename`)) AS `path`
Feb 24 18:19:50 vs1 mysqld[3665]: FROM `thread` AS t
Feb 24 18:19:50 vs1 mysqld[3665]:   INNER JOIN `post` AS p ON 
t.`newest_post` = p.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   INNER JOIN `post_content` AS pc ON 
pc.`id` = p.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   INNER JOIN `post` AS ap ON 
ap.`thread` = t.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   INNER JOIN `subforum` AS s ON 
t.`subforum` = s.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   INNER JOIN `main_forum` AS f ON 
s.`main_forum` = f.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   LEFT OUTER JOIN `thread` AS at ON 
at.`subforum` = s.`id`
Feb 24 18:19:50 vs1 mysqld[3665]:   LEFT OUTER JOIN `post` AS atp ON 
atp.`id` = at.`newest_post` AND IFNULL(atp.`modified`, atp.`created`) > 
IFNULL(p.`modified`, p.`created`)
Feb 24 18:19:50 vs1 mysqld[3665]: GROUP BY t.`id`
Feb 24 18:19:50 vs1 mysqld[3665]: ORDER BY IFNULL(p.`modified`, 
p.`created`) DESC
Feb 24 18:19:50 vs1 mysqld[3665]: LIMIT 10
Feb 24 18:19:50 vs1 mysqld[3665]: thd->thread_id=24695272
Feb 24 18:19:50 vs1 mysqld[3665]: The manual page at 
http://www.mysql.com/doc/en/Crashing.html contains
Feb 24 18:19:50 vs1 mysqld[3665]: information that should help you find 
out what is causing the crash.

Structure of tables involved in the query is attached. I don't know how 
to repeat this crash. It has happened for the first time since the site 
(and its forum) was started in 2006. Unfortunately the crash coused (or 
was coused by - it's hard to say for me) some corruption in temporary 
tables and trying to start mysqld generated other crash (log in 
forum-bug-restart1.txt) The server didn't want to start clean until I 
deleted /tmp/#sql_*.* . Then mysqlcheck reported during startup that the 
`post` and `thread` tables has not been closed properly and they should 
be checked with myisam so I did it and next restart of mysqld was 
completely clean.

-- 
Chives

-------------- next part --------------
A non-text attachment was scrubbed...
Name: forum-bug-report.sql
Type: text\plain
Size: 2741 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20080225/658acad6/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: forum-bug-restart1.txt
Url: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20080225/658acad6/attachment-0001.txt 