Bug #2580 MySQL Crash
Submitted: 30 Jan 2004 9:23 Modified: 29 Feb 2004 10:50
Reporter: Alex Corral Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S1 (Critical)
Version:4.0.14 OS:Linux (Red Hat 9)
Assigned to: CPU Architecture:Any

[30 Jan 2004 9:23] Alex Corral
Description:
We are getting this error continuing on our boxes. Can you shed some light on it ?

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=402653184
read_buffer_size=2093056
max_used_connections=6
max_connections=3800
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3359874 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8549618
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=0xbfedede8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x807474f
0x82a0ad8
0x809a4e9
0x80a6fed
0x807f46a
0x8082f6b
0x807e5b3
0x80844ee
0x807d79f
0x829e28c
0x82d199a

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
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...

thd->query at 0x85317d0 = SELECT c.id, k.id, y.id, c.title, c.description, k.bid, c.durl, y.keyword, m.account_id FROM content AS   
c, keyword_keys AS y, keywords_b AS k, members AS m, account_options AS o WHERE y.keyword = 'brides' AND k.status = '' AND 
k.keyword = y.id AND c.status = '' AND c.id = k.association AND c.account = m.account_id AND m.status!='I' AND m.account_id = 
o.account_id AND o.function = 'service-network' AND o.value!=1 AND k.bid <= m.balance ORDER BY k.bid DESC
thd->thread_id=1134
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.

How to repeat:
Startup apache web server.
[31 Jan 2004 7:12] MySQL Verification Team
Thank you very much for your report.

Does that query always crashes a server ???

If it does , check whether it crashes 4.0.17 too.

If it crashes 4.0.17, please upload tables involved to this bug record too.
[31 Jan 2004 10:20] Alex Corral
It crashes the daemon.

Actually, it's not just this query but most queries like this in general. Sometimes immediately, other times after a few minutes.
[31 Jan 2004 10:27] MySQL Verification Team
Thank you for writting this report.

This bug report forum is only for repeatable bug reports. For bug
reports like this one you should use the MySQL mailing list or buy
commercial support from MySQL AB.  

What we need is fully repeatable test case.

This test case should consist of the series of SQL commands or actaions that will always lead to the problem, in your case to the crash.

In your case all we need is a table involved in the query.

You can upload it to this bug record.
[31 Jan 2004 10:50] Heikki Tuuri
Alex,

why you do not resolve the stack traces as explained in the error message, and post the resolved stack traces here?

Also, run CHECK TABLE on your tables.

Regards,

Heikki
[14 Feb 2005 22:54] Bugs System
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".