[MDEV-3989] Server crashes on import from MariaDB mysqldump export with partitioned Aria table Created: 2012-12-28  Updated: 2013-06-14  Resolved: 2013-05-12

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.0, 5.5.28a
Fix Version/s: 10.0.3, 5.5.31

Type: Bug Priority: Major
Reporter: Risato Stefano Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux 64 bit and maybe Windows 32 bit

Attachments: File create.sql     Text File mariadb_log.txt     File truncate.sql    

 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.

 Comments   
Comment by Elena Stepanova [ 2012-12-28 ]

Hi,

>> If you need the data, it's a 100MB bzip2 file

Yes, could you please upload the file to ftp://ftp.askmonty.org/ ?
You can choose the 'private' folder there, then nobody but MariaDB developers will have access to it.

Thank you.

Comment by Risato Stefano [ 2012-12-28 ]

Ok, file uploaded, MDEV-3989_data.sql.bz2.

Comment by Elena Stepanova [ 2012-12-28 ]

Thank you for the data. I was able to reproduce the crash.

Comment by Risato Stefano [ 2013-02-19 ]

I have a table that I could not restore even if I truncate the table first. In fact with this table the server if crashing always; the only way to restore is to comment the statement "DISABLE KEYS..." in the dump file, but it takes very very long time to restore. I don't know if the problem is the same of this bug, tell me if I have to open a different bug or if you need the data file (2GB, bzipped 200MB) in the private ftp folder.

Thank you.

Comment by Elena Stepanova [ 2013-02-19 ]

Please for now upload the bzipped version under this bug report number. When the bug gets fixed, we'll check whether the the other dump starts working all right.

Comment by Risato Stefano [ 2013-02-20 ]

Uploaded:
MDEV-3989_create.sql
MDEV-3989_data.sql.xz
Bye

Comment by Risato Stefano [ 2013-04-30 ]

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.

Comment by Michael Widenius [ 2013-05-11 ]

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.

Comment by Michael Widenius [ 2013-05-12 ]

Fixed and pushed into 5.5 main tree.

Comment by Risato Stefano [ 2013-06-14 ]

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".

Generated at Thu Feb 08 06:52:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.