| Bug #52138 | mysqld-nt.exe unexpected shutdown | ||
|---|---|---|---|
| Submitted: | 17 Mar 2010 13:54 | Modified: | 25 Aug 2010 17:06 |
| Reporter: | Sergey Teslya | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 5.0.83 community-nt, 5.0.90 | OS: | Windows (Client ODBC Connector version: 2.5.0.33.00) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | dumpfile | ||
[17 Mar 2010 13:54]
Sergey Teslya
[17 Mar 2010 21:11]
MySQL Verification Team
Thank you for the bug report. According with the backtrace the offended query which caused the crash was: thd->query at 1CA801A0=SELECT GAUSSRND INTO DUMPFILE "C:\\Program Files\\RiskDataServer\\TICKERCALC\\data" FROM SIM_20091002 Upgrade you server version to 5.0.90 and try again. http://downloads.mysql.com/archives.php?p=mysql-5.0&v=5.0.90 Thanks in advance.
[18 Mar 2010 6:34]
Sergey Teslya
Thank you. We will try to upgrade server. But as you can see situation (shutdowns) repeats rarely, so we have to wait about a month before it's repeats. Now we a trying to reproduce situation in our testing environment.
[18 Mar 2010 11:02]
Sveta Smirnova
Thank you for the feedback. We will wait news from you.
[12 Apr 2010 7:56]
Sergey Teslya
Hi, We have upgraded our servers to MySQL 5.0.90 but still getting this error even more frequently. It's appear after 15 mins (average) of heavy load by queries. Here is an example of error log: 100403 20:18:27 - mysqld got exception 0xc0000005 ; 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=162529280 read_buffer_size=65536 max_used_connections=25 max_connections=160 threads_connected=22 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 209920 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=278CD1C8 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... 005EAB9F mysqld-nt.exe!_my_b_write()[mf_iocache.c:1507] 0051D118 mysqld-nt.exe!select_dump::send_data()[sql_class.cc:1548] 0054F89B mysqld-nt.exe!end_send()[sql_select.cc:11736] 005685FF mysqld-nt.exe!do_select()[sql_select.cc:10581] 00569750 mysqld-nt.exe!JOIN::exec()[sql_select.cc:2165] 00569DB4 mysqld-nt.exe!mysql_select()[sql_select.cc:2355] 0056A1FB mysqld-nt.exe!handle_select()[sql_select.cc:257] 0053BB82 mysqld-nt.exe!mysql_execute_command()[sql_parse.cc:2899] 00542A71 mysqld-nt.exe!mysql_parse()[sql_parse.cc:6449] 00543A6E mysqld-nt.exe!dispatch_command()[sql_parse.cc:1961] 00544D36 mysqld-nt.exe!do_command()[sql_parse.cc:1644] 00545055 mysqld-nt.exe!handle_one_connection()[sql_parse.cc:1233] 005F75FB mysqld-nt.exe!pthread_start()[my_winthread.c:85] 006E28EF mysqld-nt.exe!_threadstart()[thread.c:196] 77E6482F kernel32.dll!GetModuleHandleA() Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 27933D90=SELECT GAUSSRND INTO DUMPFILE "C:\\Program Files\\RiskDataServer\\TICKERCALC\\data" FROM SIM_20100312 thd->thread_id=33 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
[12 Apr 2010 8:35]
Sveta Smirnova
Thank you for the feedback. Could you please provide dump of table SIM_20100312 or at least SHOW CREATE TABLE and SHOW TABLE STATUS? Please also provide your configuration file.
[12 Apr 2010 11:55]
Sergey Teslya
MySQL config file
Attachment: my.ini (application/octet-stream, text), 9.06 KiB.
[12 Apr 2010 11:55]
Sergey Teslya
MySQL config attached. SHOW CREATE TABLE result: CREATE TABLE `sim_20100312` ( `id` int(11) NOT NULL, `seed` int(11) NOT NULL, `gaussrnd` longtext, `histweights` longtext, `dates` longtext, `traces` int(11) default NULL, `histlen` int(11) default NULL, `mv_number` int(11) default NULL, `mv` longtext, `mvids` longtext, `mvsets` longtext ) ENGINE=MyISAM DEFAULT CHARSET=latin1 SHOW TABLE STATUS IN `ticker_db` LIKE 'SIM_20100312'; RESULT: Name, Engine, Version, Row_format, Rows, Avg_row_length, Data_length, Max_data_length, Index_length, Data_free, Auto_increment, Create_time, Update_time, Check_time, Collation, Checksum, Create_options, Comment 'sim_20100312', 'MyISAM', 10, 'Dynamic', 1, 27286088, 27286088, 281474976710655, 1024, 0, , '2010-03-15 16:51:06', '2010-03-16 05:14:52', '', 'latin1_swedish_ci', , '', ''
[13 Apr 2010 9:07]
Sveta Smirnova
Thank you for the feedback. I can not repeat described behavior with test data. How much physical RAM do you have? Do you use 32-bit or 64-bit CPU?
[13 Apr 2010 9:32]
Sergey Teslya
We are using Intel Xeon X3320 CPU (2.5GHz) afaik IA-64 command set used here. With 2GB of RAM. OS: Microsoft Windows Server 2003 Web Edition Service Pack 2
[16 Apr 2010 10:49]
Sveta Smirnova
Thank you for the feedback. I still can not repeat described behavior in my environment. Error looks like memory leak. Did you notice high memory usage before crash? Do you have only this query in the error log for crashes? Which kind of queries do you use in time when crash occurs? Please provide some examples.
[4 May 2010 7:30]
Sergey Teslya
Hello, sorry for delayed feedback. Unfortunately we can perform tests on our mysql machine only on weekends since it's our production server. We've found some new details about this error. 1) We didn't noticed high memory usage before crash. 2) We are using libmysql.dll from mysql installation package as a client (not ODBC connector) there are no version information in this DLL, file date is 27/04/2006. 3) In all previous cases we've got an error on 'SELECT INTO DUMPFILE' statement, so we tryed to aviod using this statement in our application code, but that wasn't helpfull. Crash log see below. 4) As you can see every time mysql crashed while selecting from `sim_*` table, there are alot of LONGTEXT fields in this table, but we store not only textual data here, generaly it's binary data, is it make sence? Error.log 100502 19:16:39 InnoDB: Started; log sequence number 0 35886873 100502 19:16:39 [Note] C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld-nt: ready for connections. Version: '5.0.90-community-nt' socket: '' port: 3306 MySQL Community Edition (GPL) 100502 19:30:11 - mysqld got exception 0xc0000005 ; 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=162529280 read_buffer_size=65536 max_used_connections=52 max_connections=160 threads_connected=52 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 209920 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=27D010C8 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... 004D16CA mysqld-nt.exe!Protocol::net_store_data()[protocol.cc:51] 004D1F25 mysqld-nt.exe!Protocol::store_string_aux()[protocol.cc:813] 004D2F5D mysqld-nt.exe!Protocol_simple::store()[protocol.cc:956] 0045597F mysqld-nt.exe!Item_field::send()[item.cc:5230] 0051C150 mysqld-nt.exe!select_send::send_data()[sql_class.cc:1072] 0054F89B mysqld-nt.exe!end_send()[sql_select.cc:11736] 005685FF mysqld-nt.exe!do_select()[sql_select.cc:10581] 00569750 mysqld-nt.exe!JOIN::exec()[sql_select.cc:2165] 00569DB4 mysqld-nt.exe!mysql_select()[sql_select.cc:2355] 0056A1FB mysqld-nt.exe!handle_select()[sql_select.cc:257] 0053BB82 mysqld-nt.exe!mysql_execute_command()[sql_parse.cc:2899] 00542A71 mysqld-nt.exe!mysql_parse()[sql_parse.cc:6449] 00543A6E mysqld-nt.exe!dispatch_command()[sql_parse.cc:1961] 00544D36 mysqld-nt.exe!do_command()[sql_parse.cc:1644] 00545055 mysqld-nt.exe!handle_one_connection()[sql_parse.cc:1233] 005F75FB mysqld-nt.exe!pthread_start()[my_winthread.c:85] 006E28EF mysqld-nt.exe!_threadstart()[thread.c:196] 77E6482F kernel32.dll!GetModuleHandleA() Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 27D16B70=SELECT HISTWEIGHTS FROM SIM_20090505 thd->thread_id=46 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
[4 May 2010 10:55]
Sveta Smirnova
Thank you for the feedback. Problem can be MySQL allocates more than 2G RAM for retrieving BLOB values, then gets killed by operating system. Strange why I can not repeat it on my side. Please send us your configuration file also.
[4 May 2010 11:47]
Sergey Teslya
I've attached our config file, it wasn't changed from previous time. I forgot to mention - average field length in LONGTEXT fields about 16MB. May be we should enable some extra debuggin features of MySQL to give more infromation about the problem? Sergey
[25 Jul 2010 17:06]
Valeriy Kravchuk
Your last stack trace is similar to bug #25908 (it seems it was NOT fixed in 5.0.x). Please, check if any of conditions described in the comment dated [7 Mar 2007 13:27] Sergey Vojtovich there may apply to your case.
[25 Aug 2010 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".
