| Bug #34529 | Crash on complex Falcon I_S select after ALTER .. PARTITION BY | ||
|---|---|---|---|
| Submitted: | 13 Feb 2008 16:52 | Modified: | 18 Jul 2008 15:48 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Information schema | Severity: | S2 (Serious) |
| Version: | 6.0-BK | OS: | Any |
| Assigned to: | Martin Hansson | CPU Architecture: | Any |
[13 Feb 2008 16:55]
Philip Stoev
Test case for bug 34529
Attachment: bug34529.test (application/octet-stream, text), 536 bytes.
[13 Feb 2008 16:55]
Philip Stoev
stress test config file for bug 34529
Attachment: bug34529_run.txt (text/plain), 13 bytes.
[13 Feb 2008 16:59]
Philip Stoev
To reproduce, please place bug34529.test in mysqltest/t and then run: $ mysql-test-run.pl --record bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529 bug34529
[13 Feb 2008 21:50]
Kevin Lewis
The metadata being returned by Falcon is not at risk. This is a concurrency problem in the information schema code.
[13 Feb 2008 23:21]
Sveta Smirnova
Thank you for the report. Verified as descirbed.
[26 Feb 2008 14: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/42993 ChangeSet@1.2591, 2008-02-26 15:36:13+01:00, mhansson@riffraff.(none) +3 -0 Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY When swapping out heap I_S tables to disk, this is done after plan refinement. Thus, READ_RECORD::file will still point to the (deleted) heap handler at start of execution. This causes segmentation fault if join buffering is used and the query is a star query where the result is found to be empty before accessing some table. In this case that table has not been initialized (i.e. had its READ_RECORD re-initialized) before the cleanup routine tries to close the handler. Fixed by updating READ_RECORD::file when changing handler.
[27 Feb 2008 11:39]
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/43043 ChangeSet@1.2591, 2008-02-27 12:29:47+01:00, mhansson@riffraff.(none) +3 -0 Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY When swapping out heap I_S tables to disk, this is done after plan refinement. Thus, READ_RECORD::file will still point to the (deleted) heap handler at start of execution. This causes segmentation fault if join buffering is used and the query is a star query where the result is found to be empty before accessing some table. In this case that table has not been initialized (i.e. had its READ_RECORD re-initialized) before the cleanup routine tries to close the handler. Fixed by updating READ_RECORD::file when changing handler.
[14 Mar 2008 10:32]
Martin Hansson
After discussion with gluh, it's been decided that this fix should go to 5.0, 5.1 and 6.0.
[19 Mar 2008 13:37]
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/44222 ChangeSet@1.2597, 2008-03-19 14:32:28+01:00, mhansson@riffraff.(none) +3 -0 Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY When swapping out heap I_S tables to disk, this is done after plan refinement. Thus, READ_RECORD::file will still point to the (deleted) heap handler at start of execution. This causes segmentation fault if join buffering is used and the query is a star query where the result is found to be empty before accessing some table. In this case that table has not been initialized (i.e. had its READ_RECORD re-initialized) before the cleanup routine tries to close the handler. Fixed by updating READ_RECORD::file when changing handler.
[19 Mar 2008 13:40]
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/44223 ChangeSet@1.2597, 2008-03-19 14:25:19+01:00, mhansson@riffraff.(none) +3 -0 Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY When swapping out heap I_S tables to disk, this is done after plan refinement. Thus, READ_RECORD::file will still point to the (deleted) heap handler at start of execution. This causes segmentation fault if join buffering is used and the query is a star query where the result is found to be empty before accessing some table. In this case that table has not been initialized (i.e. had its READ_RECORD re-initialized) before the cleanup routine tries to close the handler. Fixed by updating READ_RECORD::file when changing handler.
[19 Mar 2008 15:39]
Sergei Glukhov
ok to push
[25 Mar 2008 16:08]
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/44413 ChangeSet@1.2603, 2008-03-25 19:44:27+04:00, gshchepa@host.loc +2 -0 information_schema.test, information_schema.result: Minor test case cleanup after bug#34529.
[28 Mar 2008 9:21]
Bugs System
Pushed into 5.1.24-rc
[28 Mar 2008 9:23]
Bugs System
Pushed into 5.0.60
[31 Mar 2008 13:58]
Bugs System
Pushed into 6.0.5-alpha
[1 Apr 2008 9:39]
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/44724 ChangeSet@1.2598, 2008-03-28 09:28:01+01:00, mhansson@riffraff.(none) +1 -0 Bug#34529: Crash on complex Falcon I_S select after ALTER .. PARTITION BY Supplementary patch that makes the test case restore current database to 'test'.
[18 Jul 2008 15:48]
Paul DuBois
Noted in 5.0.60, 5.1.24, 6.0.5 changelogs. A server crash could occur if INFORMATION_SCHEMA tables built in memory were swapped out to disk during query execution.
Description: When executing the following queries in a loop: CREATE TABLE alter1 (t1_autoinc integer not null, primary key (t1_autoinc)) ENGINE = Falcon; ALTER TABLE alter1 ENGINE = Falcon PARTITION BY HASH(t1_autoinc) PARTITIONS 2; DROP TABLE alter1; SELECT * FROM INFORMATION_SCHEMA.FALCON_TABLES INNER JOIN INFORMATION_SCHEMA.FALCON_DATABASE_IO USING (TABLESPACE) INNER JOIN INFORMATION_SCHEMA.FALCON_SERIAL_LOG_INFO ON (FALCON_TABLES.TABLESPACE = FALCON_SERIAL_LOG_INFO.DATABASE) INNER JOIN INFORMATION_SCHEMA.FALCON_TRANSACTIONS ON (FALCON_TABLES.TABLESPACE = FALCON_TRANSACTIONS.DATABASE); the server will crash after a few dozen cycles (a single thread is used). I am setting this as a Falcon bug because I am concerned that Falcon metadata is corrupted, even though the crash is in the server: #0 0x00110402 in __kernel_vsyscall () #1 0x00bdc617 in pthread_kill () from /lib/libpthread.so.0 #2 0x08434d03 in write_core (sig=11) at stacktrace.c:304 #3 0x082934b3 in handle_segfault (sig=11) at mysqld.cc:2420 #4 <signal handler called> #5 0x083b4747 in end_read_record (info=0x9c65e68) at records.cc:271 #6 0x083119e0 in st_join_table::cleanup (this=0x9c65e24) at sql_select.cc:8415 #7 0x08311ac6 in JOIN::cleanup (this=0x9c63038, full=true) at sql_select.cc:8551 #8 0x08311ca8 in JOIN::join_free (this=0x9c63038) at sql_select.cc:8474 #9 0x0831229a in do_select (join=0x9c63038, fields=0x9c05388, table=0x0, procedure=0x0) at sql_select.cc:13120 #10 0x0832dd58 in JOIN::exec (this=0x9c63038) at sql_select.cc:2755 #11 0x08328eee in mysql_select (thd=0x9c04088, rref_pointer_array=0x9c053f8, tables=0x9c41498, wild_num=1, fields=@0x9c05388, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684635648, result=0x9c5e480, unit=0x9c0506c, select_lex=0x9c052f4) at sql_select.cc:2943 #12 0x0832e07e in handle_select (thd=0x9c04088, lex=0x9c05010, result=0x9c5e480, setup_tables_done_option=0) at sql_select.cc:287 #13 0x082a2896 in execute_sqlcom_select (thd=0x9c04088, all_tables=0x9c41498) at sql_parse.cc:4639 #14 0x082a3cd0 in mysql_execute_command (thd=0x9c04088) at sql_parse.cc:1957 #15 0x082ac4da in mysql_parse (thd=0x9c04088, inBuf=0x9c410b0 "SELECT * FROM INFORMATION_SCHEMA.FALCON_TABLES\nINNER JOIN INFORMATION_SCHEMA.FALCON_DATABASE_IO USING (TABLESPACE)\nINNER JOIN INFORMATION_SCHEMA.FALCON_SERIAL_LOG_INFO ON (FALCON_TABLES.TABLESPACE = F"..., length=342, found_semicolon=0xb2740270) at sql_parse.cc:5513 #16 0x082acef3 in dispatch_command (command=COM_QUERY, thd=0x9c04088, packet=0x9c3b7a9 "", packet_length=342) at sql_parse.cc:1022 #17 0x082ae094 in do_command (thd=0x9c04088) at sql_parse.cc:714 #18 0x0829c126 in handle_one_connection (arg=0x9c04088) at sql_connect.cc:1137 #19 0x00bd750b in start_thread () from /lib/libpthread.so.0 #20 0x00b18b2e in clone () from /lib/libc.so.6 How to repeat: Test case will be provided shortly, however you can just run the queries in question in a tight loop using a single connection.