| 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: | |
| 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 | ||
[24 Jun 2010 15:33]
Shane Bester
[24 Jun 2010 15:38]
MySQL Verification Team
output from valgrind
Attachment: bug54783_valgrind_infos.txt (text/plain), 2.94 KiB.
[24 Jun 2010 16:46]
MySQL Verification Team
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]
MySQL Verification Team
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.
