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:
None 
Category:MySQL Server: Locking Severity:S1 (Critical)
Version:5.1.30 OS:Any
Assigned to: Davi Arnaut
Triage: Triaged: D1 (Critical)

[28 Nov 2008 18:23] Shane Bester
Description:
got a crash during an alter table:

 mysqld.exe!mysql_ha_close_table()[sql_handler.cc:159]
 mysqld.exe!mysql_ha_rm_tables()[sql_handler.cc:736]
 mysqld.exe!mysql_alter_table()[sql_table.cc:6080]
 mysqld.exe!mysql_execute_command()[sql_parse.cc:2797]
 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]
 mysqld.exe!_threadstart()[thread.c:275]
 kernel32.dll!BaseThreadStart()

thd->query at 00000000033B30E0=alter table `qa01` discard tablespace
thd->thread_id=267
thd->killed=NOT_KILLED

note innodb is disabled in this test, the table was myisam or memory..

How to repeat:
same gypsy teest as bug #4111
[28 Nov 2008 20:32] Shane Bester
meant to say same gypsy test as bug #41110
[1 Dec 2008 16:16] Miguel Solorzano
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] Miguel Solorzano
Could you please test with latest source if you get the same call stack?. Thanks in advance.
[4 Dec 2008 14:31] Shane Bester
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)