Bug #54783 optimize table crashes with invalid timestamp default value and NO_ZERO_DATE
Submitted: 24 Jun 2010 15:33 Modified: 30 Jul 2010 2:46
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: DDL Severity:S1 (Critical)
Version:5.5.5 OS:Any
Assigned to: Davi Arnaut CPU Architecture:Any
Tags: NO_ZERO_DATE, regression, SQL_MODE, valgrind
Triage: Triaged: D1 (Critical)

[24 Jun 2010 15:33] Shane Bester
Description:
5.5.6 stack trace:

mysqld.exe!mysql_admin_table()[sql_table.cc:5150]
mysqld.exe!mysql_optimize_table()[sql_table.cc:5226]
mysqld.exe!mysql_execute_command()[sql_parse.cc:3107]
mysqld.exe!mysql_parse()[sql_parse.cc:5911]
mysqld.exe!dispatch_command()[sql_parse.cc:1138]
mysqld.exe!do_command()[sql_parse.cc:807]
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1196]
mysqld.exe!handle_one_connection()[sql_connect.cc:1136]
mysqld.exe!pthread_start()[my_winthread.c:62]
mysqld.exe!_callthreadstartex()[threadex.c:348]
mysqld.exe!_threadstartex()[threadex.c:331]
kernel32.dll!BaseThreadStart()

attached is the full valgrind output in case you don't see a crash

How to repeat:
#run mysqld in valgrind then:
set sql_mode='';
drop table if exists `t1`;
create table `t1`(`a` int,`b` timestamp default '0000-00-00 00:00:00'
) engine=innodb partition by linear hash (`a`)partitions 1;
set session sql_mode='NO_ZERO_DATE';
optimize table `t1`;
[24 Jun 2010 15:38] Shane Bester
output from valgrind

Attachment: bug54783_valgrind_infos.txt (text/plain), 2.94 KiB.

[24 Jun 2010 16:46] Miguel Solorzano
Thank you for the bug report. Verified on Slackware 13.1 X86_64:

100624 13:38:48 [Note] ./bin/mysqld: ready for connections.
Version: '5.6.99-m4-valgrind-max-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
==21060== Thread 17:
==21060== Invalid read of size 8
==21060==    at 0x638606: mysql_admin_table(THD*, TABLE_LIST*, st_ha_check_opt*, char const*, thr_lock_type, bool, bool, unsigned int, int (*)(THD*, TABLE_LIST*, st_ha_check_opt*), int (handler::*)(THD*, st_ha_check_opt*), int (*)(THD*, TABLE_LIST*)) (sql_table.cc:5150)
==21060==    by 0x638A10: mysql_optimize_table(THD*, TABLE_LIST*, st_ha_check_opt*) (sql_table.cc:5224)
==21060==    by 0x5B4DA3: mysql_execute_command(THD*) (sql_parse.cc:3107)
==21060==    by 0x5BC86B: mysql_parse(THD*, char const*, unsigned int, Parser_state*) (sql_parse.cc:5911)
==21060==    by 0x5B047D: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1135)
==21060==    by 0x5AF714: do_command(THD*) (sql_parse.cc:807)
==21060==    by 0x69041F: do_handle_one_connection(THD*) (sql_connect.cc:1196)
==21060==    by 0x6902C9: handle_one_connection (sql_connect.cc:1135)
==21060==    by 0x4E3097F: start_thread (in /lib64/libpthread-2.11.1.so)
==21060==    by 0x40D770F: ???
==21060==  Address 0x10ad29b0 is 0 bytes inside a block of size 2,232 free'd
==21060==    at 0x4C25A28: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21060==    by 0xA0C9BC: my_no_flags_free (my_malloc.c:69)
==21060==    by 0x55ECF6: free_cache_entry(TABLE*) (sql_base.cc:888)
==21060==    by 0x560325: close_thread_table(THD*, TABLE**) (sql_base.cc:1606)
==21060==    by 0x55FA8A: close_open_tables(THD*) (sql_base.cc:1308)
==21060==    by 0x5600E1: close_thread_tables(THD*) (sql_base.cc:1549)
==21060==    by 0x638067: mysql_admin_table(THD*, TABLE_LIST*, st_ha_check_opt*, char const*, thr_lock_type, bool, bool, unsigned int, int (*)(THD*, TABLE_LIST*, st_ha_check_opt*), int (handler::*)(THD*, st_ha_check_opt*), int (*)(THD*, TABLE_LIST*)) (sql_table.cc:5061)
==21060==    by 0x638A10: mysql_optimize_table(THD*, TABLE_LIST*, st_ha_check_opt*) (sql_table.cc:5224)
==21060==    by 0x5B4DA3: mysql_execute_command(THD*) (sql_parse.cc:3107)
==21060==    by 0x5BC86B: mysql_parse(THD*, char const*, unsigned int, Parser_state*) (sql_parse.cc:5911)
==21060==    by 0x5B047D: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1135)
==21060==    by 0x5AF714: do_command(THD*) (sql_parse.cc:807)
==21060==    by 0x69041F: do_handle_one_connection(THD*) (sql_connect.cc:1196)
==21060==    by 0x6902C9: handle_one_connection (sql_connect.cc:1135)
==21060==    by 0x4E3097F: start_thread (in /lib64/libpthread-2.11.1.so)
==21060==    by 0x40D770F: ???
==21060==
[24 Jun 2010 17:29] Shane Bester
workaround: set sql_mode='';
[6 Jul 2010 17:38] 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/112964

3092 Davi Arnaut	2010-07-06
      Bug#54783: optimize table crashes with invalid timestamp default
                 value and NO_ZERO_DATE
      
      The problem was that a older version of the error path for a
      failed admin statement relied upon a few error conditions being
      met in order to access a table handler, the first one being that
      the table object pointer was not NULL. Probably due to chance,
      in all cases a table object was closed but the reference wasn't
      reset, the other conditions didn't evaluate to true. With the
      addition of a new check on the error path, the handler started
      being dereferenced whenever it was not reset to NULL, causing
      problems for code paths which closed the table but didn't reset
      the reference.
      
      The solution is to reset the reference whenever a admin statement
      fails and the tables are closed.
     @ mysql-test/r/partition_innodb.result
        Add test case result for Bug#54783
     @ mysql-test/t/partition_innodb.test
        Add test case for Bug#54783
     @ sql/sql_table.cc
        In case table recreate failed, set a appropriate result code.
        Reset reference to a closed table object, otherwise the error
        path might attempt to access it.
[6 Jul 2010 21:07] Davi Arnaut
Queued to mysql-trunk-bugfixing
[23 Jul 2010 12:25] Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100723121820-jryu2fuw3pc53q9w) (version source revid:vasil.dimov@oracle.com-20100531152341-x2d4hma644icamh1) (merge vers: 5.5.5-m3) (pib:18)
[23 Jul 2010 12:32] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100723121929-90e9zemk3jkr2ocy) (version source revid:vasil.dimov@oracle.com-20100531152341-x2d4hma644icamh1) (pib:18)
[30 Jul 2010 2:46] Paul Dubois
Noted in 5.5.6 changelog.

Incorrect error handling could result in an OPTIMIZE TABLE crash.