Bug #45070 InnoDB: Assertion failure in file srv0srv.c line 2097
Submitted: 25 May 2009 15:09 Modified: 11 Oct 2009 8:24
Reporter: Lars Lyxell Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.0.68 OS:Linux (CentOS 4.7 64-bit)
Assigned to: CPU Architecture:Any

[25 May 2009 15:09] Lars Lyxell
Description:
MySQL server crashed on fairly high load (200 q/s) with the following error message.

uname -a
Linux dbprod1 2.6.9-78.0.5.ELsmp #1 SMP Wed Oct 8 07:06:30 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

InnoDB: ###### Diagnostic info printed to the standard error stream
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
090525 16:12:45InnoDB: Assertion failure in thread 1147169120 in file srv0srv.c line 2097
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. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
090525 16:12:45 - 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.

How to repeat:
Unknown

Suggested fix:
Unknown
[25 May 2009 17:10] MySQL Verification Team
Thank you for the bug report. Please see if the same case as http://bugs.mysql.com/bug.php?id=36018. Thanks in advance.
[26 May 2009 7:18] Lars Lyxell
at least it seems like they are related but not referenced to the same source-file.

I have also uploaded the err -file

InnoDB: Warning: a long semaphore wait:
--Thread 1177528672 has waited at btr0cur.c line 3759 for 241.00 seconds the semaphore:
S-lock on RW-latch at 0x2ba3fd2cb8 created in file buf0buf.c line 497
a writer (thread id 1177528672) has reserved it in mode  exclusive
number of readers 0, waiters flag 1
Last time read locked in file btr0pcur.c line 247
Last time write locked in file buf0buf.c line 1768
InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info:
InnoDB: Pending preads 23, pwrites 0
[26 May 2009 7:19] Lars Lyxell
crash log

Attachment: mysqld.log.gz (application/x-gzip, text), 247.58 KiB.

[26 May 2009 7:50] Sveta Smirnova
Thank you for the feedback.

We had several similar bugs in past which were fixed. Could you please test with current version 5.0.81 to check if it was fixed in your case too? Please also provide your configuration file.
[26 May 2009 11:44] Lars Lyxell
Im not sure it can be reproduced as it is the first time we have seen it on this server.

So an upgrade to 5.0.81 can (and will be done) but as I cannot reproduce it and if you cannot make anything from the logs then we'll just have to hope that it does not happen again.

/lars
[26 May 2009 11:46] Lars Lyxell
my.cnf

Attachment: my.cnf (application/octet-stream, text), 1.89 KiB.

[11 Sep 2009 8:24] Sveta Smirnova
Thank you for the feedback.

Which kind of load do you experience? Please send of us example of queries, if you use transactions with multiple statements, additional details which you think is important.
[11 Oct 2009 23:00] 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".
[31 Oct 2009 4:59] James Day
Lars, the likely cause for your problem is a long-running delete statement. Check the transactions that have been running for the longest time and if a delete is among them, use WHERE or LIMIT then COMMIT to make it do less work in each transaction.