| Bug #84755 | handle_fatal_signal (sig=11) in TABLE::set_keyread | ||
|---|---|---|---|
| Submitted: | 31 Jan 2017 19:49 | Modified: | 19 Feb 2017 21:27 |
| Reporter: | Roel Van de Paar | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | MySQL Server: Information schema | Severity: | S6 (Debug Builds) |
| Version: | 5.7.16, 5.7.17 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[31 Jan 2017 19:49]
Roel Van de Paar
[31 Jan 2017 19:51]
Roel Van de Paar
This may be a new regression (TBV)
[1 Feb 2017 6:25]
MySQL Verification Team
Hello Roel, Thank you for the report. Observed that 5.7.17 debug build is affected. Thanks, Umesh
[1 Feb 2017 6:27]
MySQL Verification Team
-- 5.6.35 debug build not affected with the provided test case
[6 Feb 2017 13:41]
Erlend Dahl
Posted by developer: 5.7.9 GA displays the same behaviour. Though I question the wisdom of triggering debug sync points and then complain about asserts. Btw the INSTALL PLUGINs are bogus, they are unrelated to the 'problem'.
[6 Feb 2017 22:27]
Roel Van de Paar
Confirmed that the minimum testcase is; SET @@global.debug='+d,use_attachable_trx'; SELECT * FROM INFORMATION_SCHEMA.TABLES; I am not complaining, I am reporting. Feel free to close if the report is invalid. As for using use_attachable_trx; 1) So does MTR mysql-test/suite/innodb/t/attachable_trx.test 2) This is a part of the testcase in #1: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION; SET @@global.debug = '+d,use_attachable_trx'; SELECT * FROM t1; <<<<<<<< This testcase; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION; SET @@global.debug='+d,use_attachable_trx'; SELECT * FROM INFORMATION_SCHEMA.TABLES; <<<<<<<< Crashes the server all the same as above. So, it is a situation not covered in MTR. 3) This does not crash; CREATE TABLE t1 (id int); # does not matter if this is inside the trx or not SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION; SET @@global.debug = '+d,use_attachable_trx'; SELECT * FROM t1; 4) The crash is in cost model (introduced in 5.7) and 5.6.35 does not crash on the testcase (it provides the results requested). My preliminary conclusion is; 1) The testcase could be expanded 2) There is a regression in the use_attachable_trx testcode in that it does not cater for the cost model 3) The cost model does not accommodate for use_attachable_trx when an I_S table is involved 4) The cost model does accommodate for use_attachable_trx when a normal table is involved TLDR; The issue may not or may be significant, but there does seem to be a quality shortcoming
[6 Feb 2017 22:27]
Roel Van de Paar
.
[8 Feb 2017 13:10]
Erlend Dahl
Your testcase sets a debug flag. These flags are used within the server to simulate an internal failure or to force a certain behaviour. This is not possible for normal users of the production version. Their use is in carefully crafted testcases that take these intended behaviour changes into account. Used in another context, there is no guarantee they will work at all, and no point in trying to make them do so. Such flags are in our opinion not suitable for randomized testing, and the fact that they create asserts or crashes can't be used to draw conclusions about regressions or quality of the server. In our opinion, you should remove the use of debug flags from your scripts.
[19 Feb 2017 21:27]
Roel Van de Paar
I've removed the debug code from testing SQL. It's a bit with mixed feelings as we did find product shortcoming this way, but I also appreciate that the eventual ROI is not significant enough (unless substantial changes in the whole industry happen - i.e. more focus on perfect quality in favor of new features).
