Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.0, 5.5.28a
-
None
-
None
-
Linux 64 bit and maybe Windows 32 bit
Description
The original description can be found at the end of this field. I've left it intact along with the summary for the reference of end users, as that's the symptoms they are likely to see.
The following test case is a simplified extract from a dump file produced by mysqldump. It causes valgrind errors 'Invalid read' which, I suppose, is a root cause of the observed and described crash.
--source include/have_partition.inc
|
|
|
CREATE TABLE t1 ( |
a SMALLINT NOT NULL DEFAULT '0', |
b CHAR(15) NOT NULL DEFAULT '', |
KEY (b) |
) ENGINE=Aria
|
PARTITION BY LIST (a) ( |
PARTITION p1 VALUES IN (1), |
PARTITION p2 VALUES IN (2) |
);
|
LOCK TABLES t1 WRITE;
|
ALTER TABLE t1 DISABLE KEYS; |
==4671== Thread 4:
|
==4671== Invalid read of size 8
|
==4671== at 0x95B3B9: maria_status (ma_info.c:45)
|
==4671== by 0x972830: ha_maria::info(unsigned int) (ha_maria.cc:2433)
|
==4671== by 0x9710D1: ha_maria::disable_indexes(unsigned int) (ha_maria.cc:1873)
|
==4671== by 0x7D75C4: handler::ha_disable_indexes(unsigned int) (handler.cc:3571)
|
==4671== by 0xCAB2C6: ha_partition::disable_indexes(unsigned int) (ha_partition.cc:7532)
|
==4671== by 0x7D75C4: handler::ha_disable_indexes(unsigned int) (handler.cc:3571)
|
==4671== by 0x6B2398: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool) (sql_table.cc:6248)
|
==4671== by 0x94CF2B: Alter_table_statement::execute(THD*) (sql_alter.cc:106)
|
==4671== by 0x61791F: mysql_execute_command(THD*) (sql_parse.cc:4460)
|
==4671== by 0x61AAC2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5737)
|
==4671== by 0x60E28F: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1055)
|
==4671== by 0x60D546: do_command(THD*) (sql_parse.cc:794)
|
==4671== by 0x715A44: do_handle_one_connection(THD*) (sql_connect.cc:1253)
|
==4671== by 0x71542F: handle_one_connection (sql_connect.cc:1168)
|
==4671== by 0xBB7C10: pfs_spawn_thread (pfs.cc:1015)
|
==4671== by 0x5458EFB: start_thread (pthread_create.c:304)
|
==4671== Address 0x118b38d0 is 16 bytes inside a block of size 128 free'd
|
==4671== at 0x4C282E0: free (vg_replace_malloc.c:366)
|
==4671== by 0xCDBA99: my_free (my_malloc.c:115)
|
==4671== by 0x95DE6C: _ma_trnman_end_trans_hook (ma_state.c:532)
|
==4671== by 0x977E14: trnman_end_trn (trnman.c:479)
|
==4671== by 0x9ABF33: ma_commit (ma_commit.c:38)
|
==4671== by 0x9738D2: ha_maria::implicit_commit(THD*, bool) (ha_maria.cc:2825)
|
==4671== by 0x7D22F8: ha_commit_trans(THD*, bool) (handler.cc:1185)
|
==4671== by 0x727EF0: trans_commit_implicit(THD*) (transaction.cc:224)
|
==4671== by 0x610B16: mysql_execute_command(THD*) (sql_parse.cc:2114)
|
==4671== by 0x61AAC2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5737)
|
==4671== by 0x60E28F: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1055)
|
==4671== by 0x60D546: do_command(THD*) (sql_parse.cc:794)
|
==4671== by 0x715A44: do_handle_one_connection(THD*) (sql_connect.cc:1253)
|
==4671== by 0x71542F: handle_one_connection (sql_connect.cc:1168)
|
==4671== by 0xBB7C10: pfs_spawn_thread (pfs.cc:1015)
|
==4671== by 0x5458EFB: start_thread (pthread_create.c:304)
|
revision-id: sergii@pisem.net-20121206163022-iyc7rupgh2oete89
|
date: 2012-12-06 17:30:22 +0100
|
revno: 3604
|
branch: maria/5.5
|
Also reproducible on current 10.0-base.
Not reproducible with MyISAM instead of Aria.
Could not reproduce on maria/5.3.
===========================
Original description
The problem doesn't affect the same table using MyISAM instead of Aria. The dump is created with default options of the mysqldump.exe included in MariaDB 5.5.28a Windows 32 bit version. The file created contains both the create statement and the insert statements, and the problem occours randomly after restoring about 100-200 MB of data. If I create two separate files for create table and inserts (I did it splitting the original dump file with "head" and "tail" commands), and I run the file separately, the problem doesn't occurs. Example:
mysql mydb < dump.sql (crash)
mysql mydb < create.sql; mysql mydb < data.sql (ok)
cat create.sql data.sql | mysql mydb (crash)
cat create.sql truncate.sql data.sql (ok)
Inserting a truncate table statement between the create table and the inserts, the problem doesn't occours.
Affected versions are 5.5.28a and 10.0.0 Linux 64 bit (under Ubuntu 12.04). On Windows Seven 32 bit, 5.5.28a, I get the problem the first time I tried, but not the second time. I attach the output of the server and the create table statement. If you need the data, it's a 100MB bzip2 file.
Attachments
Activity
Hello, I've tested the 10.0.0.2, and now the server doesn't crash anymore, but the operation fail anyway with the error:
ERROR 1034 (HY000) at line 21: Incorrect key file for table 'datiulteriori'; try to repair it
Thank you, bye.
This is probably the same issue as with MDEV-3999.
I will test this as soon as I am ready with testing my bug fix for 3999.
I have tested the 10.0.0.3 linux 64, and the server doesn't crash anymore, but the operation still fails after about 500MB loaded with error "ERROR 2013 (HY000) at line 879: Lost connection to MySQL server during query".
Uploaded:
MDEV-3989_create.sqlMDEV-3989_data.sql.xzBye