| Bug #18311 | MySQL Server crashes with "got signal 6" | ||
|---|---|---|---|
| Submitted: | 17 Mar 2006 15:42 | Modified: | 27 Aug 2006 10:37 |
| Reporter: | Florian Engelhardt | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.0.21, 5.0.19 | OS: | Linux (Linux-2.6.12) |
| Assigned to: | CPU Architecture: | Any | |
[17 Mar 2006 15:42]
Florian Engelhardt
[17 Mar 2006 15:48]
Florian Engelhardt
Right now, after i restarted the database, it happend again, with exact the same backtrace. FYI: We are using the binary from mysql.com
[18 Mar 2006 16:23]
Valeriy Kravchuk
Thank you for a problem report. Please, send the SHOW CREATE TABLE results for the tables mentioned in your query. Is it possible?
[20 Mar 2006 9:20]
Florian Engelhardt
Ok, i am collecting the data, this is very much. would it be ok, if i post it as "hide from public" ?
[20 Mar 2006 11:07]
Florian Engelhardt
We had some discussions here, and now we can give you the table layout, but not the data in this tables. is that ok for you? The structure with all triggers, functions, stored procedures and of course tables will be very large.
[21 Mar 2006 13:03]
Valeriy Kravchuk
Yes, you can submit your table structures without data, as a comment hidden from public. I am almost sure your data will not be needed. I also do not really need triggers and SPs, as crash was on SELECT.
[3 Apr 2006 12:09]
Tordjman Yohan
Another traces: *** glibc detected *** double free or corruption (!prev): 0x8cbcd8c0 *** mysqld got signal 6; 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=524288000 read_buffer_size=2093056 max_used_connections=154 max_connections=600 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2967195 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x89609638 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=0x966fe768, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8166358 0xffffe420 0x8960a5cc 0xb7d76545 0xb7d7cb97 0xb7d7d032 0x82cd970 0x8187bc5 0x8189804 0xb7fa6ced 0xb7de7d7e 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=698185 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 *** glibc detected *** double free or corruption (!prev): 0x09708048 *** mysqld got signal 6; 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=524288000 read_buffer_size=2093056 max_used_connections=50 max_connections=600 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2967195 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x916a6fc0 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=0x955fe768, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8166358 0xffffe420 0x916a7f54 0xb7d61545 0xb7d67b97 0xb7d68032 0x82cd970 0x8187bc5 0x8189804 0xb7f91ced 0xb7dd2d7e 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=3596 The manual page at http://www.mysql.com/doc/en/Crashing.html contains
[24 Apr 2006 15:29]
Valeriy Kravchuk
Let's concentrate on the first problematic query:
select sum(price) from (
select ifnull(sum(price) * if(min(price)=0.0000,0,1),0.0000) as price
from RONSHOP_DISPATCH_LIMITS
where
(dispatch_limit_group_id,dispatch_type_id,ifnull(from_value,-1)
,ifnull(from_amount,-1),dispatch_country_id,currency_id)
in
(
select rdl.dispatch_limit_group_id,rdl.dispatch_type_id
,ifnull(max(from_value),-1),ifnull(max(from_amount),-1),iCountryId,iCurrencyId
from RONSHOP_DISPATCH_LIMITS rdl
left outer join RONSHOP_VIEW_ORDER_DISPATCH_LIMIT_GROUP rvodlg
on rvodlg.dispatch_limit_group_id=rdl.dispatch_limit_group_id
and rdl.dispatch_type_id=rvodlg.dispatch_id
and if(from_amount is
NULL,from_value<=sum_price_net,from_amount<=sum_amount)
where rvodlg.dispatch_id is NOT NULL
and rdl.dispatch_country_id=iCountryId
and rdl.currency_id=iCurrencyId
and rvodlg.order_id=p_cartid
group by rdl.dispatch_limit_group_id,rdl.dispatch_type_id
) group by dispatch_type_id) a;
I hope it is complete. Please, send the EXPLAIN results for this query. Try to repeat on a newer version, 5.0.20a, also.
[25 Apr 2006 8:40]
Florian Engelhardt
i attached the resultset of the explain command of this query. I tried with a new version (5.0.20a, binary and self compiled and also with the source downloaded via bitkeeper client yesterday), same error.
[25 Apr 2006 8:49]
Florian Engelhardt
@Valeriy Kravchuk: Your Comment from [21 Mar 14:03]: This is a select, but this select is in a stored procedure.
[17 May 2006 21:53]
Valeriy Kravchuk
Can you repeat the crash outside the stored procedure? Please, send you my.cnf file content. How much RAM do you have?
[18 May 2006 8:12]
Florian Engelhardt
The machine has 2 GB RAM. We will try to repeat the crash outside the procedure with 5.0.21. I will report back when done. I will attach our my.cnf file
[18 May 2006 19:27]
Valeriy Kravchuk
Thank you for the additional information. Have you got the crash in 5.0.21?
[19 May 2006 7:47]
Florian Engelhardt
Yes, we tried every new version since 5.0.19. Same crash in the same procedure on every version newer than 5.0.19 The older versions (5.0.18 and older) have a dead lock, that was fixed in 5.0.19, but that fix (or another fix or change) coused this "got signal 6".
[27 May 2006 14:30]
Valeriy Kravchuk
What version of glibc do you use? Please, try to repeat with 5.0.21 using static binaries from MySQL, and inform about the results.
[16 Jun 2006 8:41]
Dario Binetti
OS: Linux x86_64 kernel 2.6.9-34.0.1.ELlargesmp MySQL versione 5.0.22 Error: *** glibc detected *** free(): invalid next size (normal): 0x00000000011c4b50 *** mysqld got signal 6; 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=3221225472 read_buffer_size=4190208 max_used_connections=297 max_connections=300 threads_connected=185 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 14203725 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. For 3 times in the same day, last time immediately after restart from the 2nd time. HELP!!!
[26 Jun 2006 12:10]
Elmar Pruesse
I seem to have the same problem here inserting a dump from our 4.0 server on the new amd64 hardware. There definetely is enough memory! I assume it's on an insert statement here.
[27 Jun 2006 8:05]
Florian Engelhardt
Hell Valeriy Kravchuk, we tried with 5.0.21 with the mysql binaries and the self compiled version, still the same problem. glibc version is: 2.3.5 Kind regards Florian
[27 Jun 2006 9:25]
Dario Binetti
The solution that I had used to correct the problem, is reinstall Linux with swap area= 2* RAM(for the first 2G RAM) + RAM - 2GB In my case (16 GB RAM) swap area is 2*2GB-14GB=18GB or (better) 9 swap area of 2GB. My linux version is RedHat AS 4.0 update 3 Kernel 2.6.9-34.0.1.ELlargesmp 4 CPU DUAL CORE HT 3GHz (16 vitual cpus) 16GB RAM bye
[15 Jul 2006 15:15]
Valeriy Kravchuk
Florian, I am unabe to download the file you mentioned in your private comment on [21 Mar 14:07]. Please, add a comment on where can I find it again (looks like it was deleted/not loaded here really). What exact procedure should I call?
[17 Jul 2006 8:16]
Florian Engelhardt
I just uploaded that file again, i deleted it some two or three weeks ago, i thought you allready downloaded it.
[17 Jul 2006 8:47]
Dario Binetti
In MySQL network (if you buy a subscription) was certified the version 5.0.17c With this version I have no problem (with 5.0.22 mysql crashed 2 o 3 times a day!!!) bye
[17 Jul 2006 11:07]
Valeriy Kravchuk
Sorry, I had downloaded it, but with .txt extension (for some unknown reason), so I missed it while searching. Anyway, downloaded again. You can delete it now.
[27 Jul 2006 10:37]
Valeriy Kravchuk
Florian, In your last crash information I had found: key_buffer_size=3221225472 read_buffer_size=4190208 max_used_connections=297 max_connections=300 threads_connected=185 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 14203725 K bytes of memory that is, a lot of memory (much more than 2G) might be used by MySQL server. Please, send your current my.cnf content. Have you identified complete statement(s) that give you this crash? Those from your initial report does not work on your schema (for me).
[27 Aug 2006 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".
