| Bug #53471 | row_merge_drop_temp_indexes() refers freed memory, SEGVs | ||
|---|---|---|---|
| Submitted: | 6 May 2010 22:52 | Modified: | 14 Dec 2010 19:24 |
| Reporter: | Mikhail Izioumtchenko | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB Plugin storage engine | Severity: | S2 (Serious) |
| Version: | mysql-5.1-innodb | OS: | Any |
| Assigned to: | Marko Mäkelä | CPU Architecture: | Any |
[12 May 2010 5: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/108064
[12 May 2010 5: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/108065
[12 May 2010 5:44]
Marko Mäkelä
Thanks for the suggested fix, Michael! I would just rename the variable from "prev_index" to "next_index". Sorry, my mistake.
We do not test for these recovery conditions in mysql-test-run. I guess we should write tests with some sort of DBUG_EXECUTE_IF("crash_ddl", abort();); and SET SESSION debug="d,crash_ddl". See crash_commit_before.test in the main suite. It triggers an intentional crash in handler.cc.
[12 May 2010 5:56]
Sunny Bains
OK to push.
[12 May 2010 16:26]
Mikhail Izioumtchenko
strange that I called the variable 'prev_index' :) I've always thought a lot could be done with mtr that is done usually. For the case with multiple indexes, though, we'd need more coding. One thread should reach a certain point and suspend itself there while the next one, crash mysqld. A static counter enabled by DBUG_ON should do it.
[31 May 2010 8:28]
Bugs System
Pushed into 5.1.48 (revid:vasil.dimov@oracle.com-20100531082307-9x08gg1g7zybx2jy) (version source revid:vasil.dimov@oracle.com-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:16)
[17 Jun 2010 6:13]
Bugs System
Pushed into 5.5.5-m3 (revid:alexey.kopytov@sun.com-20100615145247-8bj0vmuqlotbqsn9) (version source revid:marko.makela@oracle.com-20100512053925-ovwmpo0838fs2roo) (merge vers: 5.1.48) (pib:16)
[17 Jun 2010 6:16]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615150216-cubqoyn1fj9b6a2p) (version source revid:marko.makela@oracle.com-20100512053925-ovwmpo0838fs2roo) (pib:16)
[27 Jul 2010 20:19]
John Russell
Internally generated bug, closing without updating change log.
[14 Oct 2010 8:32]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.51-ndb-7.0.20 (revid:martin.skold@mysql.com-20101014082627-jrmy9xbfbtrebw3c) (version source revid:vasil.dimov@oracle.com-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)
[14 Oct 2010 8:48]
Bugs System
Pushed into mysql-5.1-telco-6.3 5.1.51-ndb-6.3.39 (revid:martin.skold@mysql.com-20101014083757-5qo48b86d69zjvzj) (version source revid:vasil.dimov@oracle.com-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)
[14 Oct 2010 9:02]
Bugs System
Pushed into mysql-5.1-telco-6.2 5.1.51-ndb-6.2.19 (revid:martin.skold@mysql.com-20101014084420-y54ecj85j5we27oa) (version source revid:vasil.dimov@oracle.com-20100513074652-0cvlhgkesgbb2bfh) (merge vers: 5.5.5-m3) (pib:21)
Description: the following bit of code in row_merge_drop_temp_indexes() isn't right and indeed results in an occasional SEGV in my stress tests. for (index = dict_table_get_first_index(table); index; index = dict_table_get_next_index(index)) { if (*index->name == TEMP_INDEX_PREFIX) { row_merge_drop_index(index, table, trx); trx_commit_for_mysql(trx); } } the problem is, row_merge_drop_index() frees the memory that index point to, so the step computation in the loop may result in bad 'index' value. How to repeat: see code, SEGVs in my stress tests sometimes Suggested fix: rewrite the loop to compute the next index pointer before calling row_merge_drop_index()