| Bug #41112 | crash in mysql_ha_close_table/get_lock_data with alter table | ||
|---|---|---|---|
| Submitted: | 28 Nov 2008 18:23 | Modified: | 18 Mar 2009 14:48 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S1 (Critical) |
| Version: | 5.1.30 | OS: | Any |
| Assigned to: | Davi Arnaut | CPU Architecture: | Any |
[28 Nov 2008 18:23]
Shane Bester
[28 Nov 2008 20:32]
MySQL Verification Team
meant to say same gypsy test as bug #41110
[1 Dec 2008 16:16]
MySQL Verification Team
I got a little different call stack: 081201 13:56:49 [Note] Event Scheduler: Loaded 0 events 081201 13:56:49 [Note] c:\dbs\5.1\bin\mysqld: ready for connections. Version: '5.1.31-nt-debug-log' socket: '' port: 3510 Source distribution Assertion failed: 0, file .\protocol.cc, line 416 Assertion failed: 0, file .\protocol.cc, line 416 Assertion failed: 0, file .\protocol.cc, line 416 Assertion failed: 0, file .\protocol.cc, line 416 081201 14:12:39 - mysqld got exception 0x80000003 ; 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=8388572 read_buffer_size=131072 max_used_connections=6 max_threads=151 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337711 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x1f1ecf0 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... 009C3A84 mysqld.exe!_NMSG_WRITE()[crt0msg.c:195] 009B200A mysqld.exe!abort()[abort.c:44] 009AF772 mysqld.exe!_assert()[assert.c:306] 005A26B4 mysqld.exe!net_end_statement()[protocol.cc:416] 006700BE mysqld.exe!dispatch_command()[sql_parse.cc:1566] 0066EBF7 mysqld.exe!do_command()[sql_parse.cc:857] 0077F8C4 mysqld.exe!handle_one_connection()[sql_connect.cc:1115] 00848686 mysqld.exe!pthread_start()[my_winthread.c:85] 009B7BB7 mysqld.exe!_threadstart()[thread.c:196] 7C80B713 kernel32.dll!GetModuleFileNameA() Trying to get some variables.
[1 Dec 2008 16:33]
MySQL Verification Team
Could you please test with latest source if you get the same call stack?. Thanks in advance.
[4 Dec 2008 14:31]
MySQL Verification Team
yes debug binary will assert like this. release binary will produce the crash sometimes (mostly bug #41110 is hit, but about 1/20 times this one is hit). Here's another stack trace from release binary: mysqld.exe!get_lock_data()[lock.cc:828] mysqld.exe!mysql_lock_tables()[lock.cc:214] mysqld.exe!mysql_ha_read()[sql_handler.cc:480] mysqld.exe!mysql_execute_command()[sql_parse.cc:3933] mysqld.exe!mysql_parse()[sql_parse.cc:5791] mysqld.exe!dispatch_command()[sql_parse.cc:1202] mysqld.exe!do_command()[sql_parse.cc:857] mysqld.exe!handle_one_connection()[sql_connect.cc:1115] mysqld.exe!pthread_start()[my_winthread.c:85] mysqld.exe!_callthreadstart()[thread.c:295]
[9 Feb 2009 13:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/65605 2793 Davi Arnaut 2009-02-09 Bug#41110: crash with handler command when used concurrently with alter table Bug#41112: crash in mysql_ha_close_table/get_lock_data with alter table The problem is that the server wasn't handling robustly failures to re-open a table during a HANDLER .. READ statement. If the table needed to be re-opened due to it's storage engine being altered to one that don't support HANDLER, a reference (dangling pointer) to a closed table could be left in place and accessed in later attempts to fetch from the table using the handler. Also, if the server failed to set a error message if the re-open failed. These problems could lead to server crashes or hangs. The solution is to remove any references to a closed table and to set a error if reopening a table during a HANDLER .. READ statement fails.
[24 Feb 2009 9:22]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/67316 2760 Davi Arnaut 2009-02-24 Bug#41110: crash with handler command when used concurrently with alter table Bug#41112: crash in mysql_ha_close_table/get_lock_data with alter table The problem is that the server wasn't handling robustly failures to re-open a table during a HANDLER .. READ statement. If the table needed to be re-opened due to it's storage engine being altered to one that doesn't support HANDLER, a reference (dangling pointer) to a closed table could be left in place and accessed in later attempts to fetch from the table using the handler. Also, if the server failed to set a error message if the re-open failed. These problems could lead to server crashes or hangs. The solution is to remove any references to a closed table and to set a error if reopening a table during a HANDLER .. READ statement fails. There is no test case in this change set as the test depends on a testing feature only available on 5.1 and later. @ sql/sql_handler.cc Remove redundant reopen check. Set errors even if reopening table. Reset TABLE_LIST::table reference when the table is closed.
[24 Feb 2009 9:56]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/67329 2812 Davi Arnaut 2009-02-24 [merge] Bug#41110: crash with handler command when used concurrently with alter table Bug#41112: crash in mysql_ha_close_table/get_lock_data with alter table The problem is that the server wasn't handling robustly failures to re-open a table during a HANDLER .. READ statement. If the table needed to be re-opened due to it's storage engine being altered to one that doesn't support HANDLER, a reference (dangling pointer) to a closed table could be left in place and accessed in later attempts to fetch from the table using the handler. Also, if the server failed to set a error message if the re-open failed. These problems could lead to server crashes or hangs. The solution is to remove any references to a closed table and to set a error if reopening a table during a HANDLER .. READ statement fails. @ mysql-test/include/handler.inc Add test case for Bug#41110 and Bug#41112 @ mysql-test/r/handler_innodb.result Add test case result for Bug#41110 and Bug#41112 @ mysql-test/r/handler_myisam.result Add test case result for Bug#41110 and Bug#41112 @ sql/sql_handler.cc Remove redundant reopen check. Set errors even if reopening table. Reset TABLE_LIST::table reference when the table is closed.
[24 Feb 2009 9:59]
Davi Arnaut
Queued to 5.0-bugteam, 5.1-bugteam and 6.0-bugteam
[9 Mar 2009 14:12]
Bugs System
Pushed into 5.0.79 (revid:joro@sun.com-20090309135922-a0di9ebkxoj4d4wv) (version source revid:aelkin@mysql.com-20090224143545-7xc77386o8mg623c) (merge vers: 5.0.79) (pib:6)
[13 Mar 2009 1:45]
Paul DuBois
Noted in 5.0.79 changelog. The server did not robustly handle problems hang if a table opened with HANDLER needed to be re-opened because it had been altered to use a different storage engine that does not support HANDLER. The server also failed to set an error if the re-open attempt failed. These problems could cause the server to crash or hang. Setting report to NDI pending push into 5.1.x/6.0.x
[13 Mar 2009 19:05]
Bugs System
Pushed into 5.1.33 (revid:joro@sun.com-20090313111355-7bsi1hgkvrg8pdds) (version source revid:patrick.crews@sun.com-20090225081629-ent6zn9d1lt6bx68) (merge vers: 5.1.33) (pib:6)
[14 Mar 2009 1:37]
Paul DuBois
Noted in 5.1.33 changelog. Setting report to NDI pending push into 6.0.x.
[18 Mar 2009 13:19]
Bugs System
Pushed into 6.0.11-alpha (revid:joro@sun.com-20090318122208-1b5kvg6zeb4hxwp9) (version source revid:davi.arnaut@sun.com-20090224102254-36qv5h5k1j1tmfsw) (merge vers: 6.0.10-alpha) (pib:6)
[18 Mar 2009 14:48]
Paul DuBois
Noted in 6.0.11 changelog.
[9 May 2009 16:44]
Bugs System
Pushed into 5.1.34-ndb-6.2.18 (revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (version source revid:jonas@mysql.com-20090508100057-30ote4xggi4nq14v) (merge vers: 5.1.33-ndb-6.2.18) (pib:6)
[9 May 2009 17:41]
Bugs System
Pushed into 5.1.34-ndb-6.3.25 (revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (version source revid:jonas@mysql.com-20090508175813-s6yele2z3oh6o99z) (merge vers: 5.1.33-ndb-6.3.25) (pib:6)
[9 May 2009 18:38]
Bugs System
Pushed into 5.1.34-ndb-7.0.6 (revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (version source revid:jonas@mysql.com-20090509073226-09bljakh9eppogec) (merge vers: 5.1.33-ndb-7.0.6) (pib:6)
