Bug #52317 | Assertion failing in Field_varstring::store () at field.cc:6833 | ||
---|---|---|---|
Submitted: | 23 Mar 2010 22:44 | Modified: | 13 Aug 2010 2:15 |
Reporter: | Patrick Crews | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
Version: | 5.6, 6.0 | OS: | Any |
Assigned to: | Øystein Grøvlen | CPU Architecture: | Any |
Tags: | assertion, crashing bug |
[23 Mar 2010 22:44]
Patrick Crews
[23 Mar 2010 22:58]
Patrick Crews
Full mtr test case with both simplified and original queries
Attachment: bug52137_test.txt (text/plain), 8.42 KiB.
[23 Mar 2010 22:59]
Patrick Crews
Full crash output
Attachment: bug52317_backtrace.txt (text/plain), 14.61 KiB.
[26 Mar 2010 8:46]
Jørgen Løland
Seems to be related to BUG#49906
[30 Mar 2010 19:23]
Patrick Crews
I am also seeing this crash for other types such as Field_long, etc.
[7 Apr 2010 9:25]
Tor Didriksen
I see this crash in next-mr as well, but *not* in 5.1
[7 Apr 2010 14:18]
Tor Didriksen
bzrfind in mysql-next-mr-bugfixing says: # Revision jorgen.loland@sun.com-20100311102910-tsbh5nal1qz73fjd: test FAILED # Regression source: jorgen.loland@sun.com-20100311102910-tsbh5nal1qz73fjd jorgen.loland@sun.com-20100311102910-tsbh5nal1qz73fjd which is the fix for Bug #50257 Missing info in REF column of the EXPLAIN lines for subselects
[9 Apr 2010 13:11]
Manyi Lu
Developer, please check if this one is a duplicate of 52717.
[12 Apr 2010 6:06]
Tor Didriksen
Seems to be duplicate of Bug #52717 Assert in EXPLAIN SELECT with very particular combination with ANY and index
[14 Apr 2010 9:27]
Tor Didriksen
This bug was tagged SRFEATURE and version 6.0 Then I discovered it applies to other trees as well, so I asked for a re-triage.
[16 Apr 2010 12:15]
Øystein Grøvlen
Fails in next-mr, but not in trunk.
[19 Apr 2010 9:35]
Øystein Grøvlen
Observations: - get_store_key() returns a store_key_const_item for key on CC.col_varchar_key. - This occurs because keyuse->used_tables is empty. - Later, store_key_const_item::copy_inner() is called. - Unlike store_key_item::copy_inner() is does not try to modify the write_set of the table. - Assert hits because one is trying to copy into a field which is not in the write set. It seems to me that either keyuse->used_tables should have been set, or one should not try to copy into this field.
[19 Apr 2010 9:36]
Øystein Grøvlen
A minimal test case: CREATE TABLE t1 (i INTEGER); INSERT INTO t1 VALUES (1); CREATE TABLE t2 (i INTEGER, KEY k(i)); INSERT INTO t2 VALUES (1), (2); EXPLAIN SELECT i FROM t1 WHERE (1) NOT IN (SELECT i FROM t2); DROP TABLE t2; DROP TABLE t1;
[20 Apr 2010 8:54]
Øystein Grøvlen
The following query fails the same way in next-mr, but not does not fail in 6.0-codebase: EXPLAIN SELECT i FROM t1 WHERE (1) IN (SELECT i FROM t2)
[20 Apr 2010 8:59]
Øystein Grøvlen
Note that the above comment about 6.0-codebase, was with semijoin turned off, so execution should be equivalent.
[20 Apr 2010 9:08]
Øystein Grøvlen
(Continuing discussion with myself ...) My previous comment was wrong. Materialization also needs to be turned off to get same execution path in 6.0-codebase as in next-mr. If that is done, IN-query also fail sin 6.0-codebase.
[20 Apr 2010 9:32]
Øystein Grøvlen
In trunk, where the fix for Bug#50257, is not (yet?) present, a store_key_item is created instead of a store_key_const_item. Hence, writing to the associated field is allowed.
[21 Apr 2010 7:05]
Øystein Grøvlen
The following change, fixes the issue, but also changes the explain output in some cases (replacing const with func in ref column) so I am not certain it is correct: === modified file 'sql/sql_select.cc' --- sql/sql_select.cc 2010-04-01 19:34:09 +0000 +++ sql/sql_select.cc 2010-04-20 12:57:23 +0000 @@ -5926,7 +5926,7 @@ get_store_key(THD *thd, KEYUSE *keyuse, table_map used_tables, KEY_PART_INFO *key_part, uchar *key_buff, uint maybe_null) { - if (!((~used_tables) & keyuse->used_tables)) // if const item + if (!((~used_tables) & keyuse->used_tables) && !thd->lex->describe) // if const item { return new store_key_const_item(thd, key_part->field,
[23 Apr 2010 9:29]
Øystein Grøvlen
The issue here is related to the fact that subqueries are executed as part of EXPLAIN. Hence, unlike for "top-level queries", store_key_const_item::copy_inner() will actually be called. This is different for normal execution of subqueries where a temporary store_key_item object is used instead. So if we are to continue to use the trick with store_key_const_item for EXPLAIN, I think we will have to allow writing into the underlying field for store_key_const_item as we do for store_key_item.
[23 Apr 2010 12:23]
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/106428 3150 oystein.grovlen@sun.com 2010-04-23 Bug#52317 Assertion failing in Field_varstring::store () at field.cc:6833 In order for EXPLAIN to print const-refs, a Store_key_const_item object is created. This is different for normal execution of subqueries where a temporary store_key_item object is used instead. The problem is that EXPLAIN will execute subqueries. This leads to a scenario where a store_key_const_item object it told to write to its underlying field. This results in a failing assert since the write set of the underlying table does not reflect this. The resolution is to do the same trick as for store_key_item::copy_inner(). That is, temporarily change the write set to allow writes to all columns. This is only necessary in debug version since non-debug version does not contain asserts on write_set. @ mysql-test/r/subselect4.result Test case for Bug#52317 @ mysql-test/t/subselect4.test Test case for Bug#52317 @ sql/sql_select.h Temporarily change write_set in store_key_const_item::copy_inner() to allow initialization of underlying field. This is necessary since subqueries are executed for EXPLAIN. (For normal execution, store_key_item::copy_inner is used.)
[23 Apr 2010 12:36]
Øystein Grøvlen
"Voluteering" Tor since he did some early investigation of this bug and Evgeny since he reviewed the patch that introduced this regression.
[27 May 2010 6:47]
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/109313 3204 oystein.grovlen@sun.com 2010-05-27 Bug#52317 Assertion failing in Field_varstring::store () at field.cc:6833 In order for EXPLAIN to print const-refs, a Store_key_const_item object is created. This is different for normal execution of subqueries where a temporary store_key_item object is used instead. The problem is that EXPLAIN will execute subqueries. This leads to a scenario where a store_key_const_item object it told to write to its underlying field. This results in a failing assert since the write set of the underlying table does not reflect this. The resolution is to do the same trick as for store_key_item::copy_inner(). That is, temporarily change the write set to allow writes to all columns. This is only necessary in debug version since non-debug version does not contain asserts on write_set. @ mysql-test/r/subselect4.result Test case for Bug#52317 @ mysql-test/t/subselect4.test Test case for Bug#52317 @ sql/sql_select.h Temporarily change write_set in store_key_const_item::copy_inner() to allow initialization of underlying field. This is necessary since subqueries are executed for EXPLAIN. (For normal execution, store_key_item::copy_inner is used.)
[27 May 2010 7:28]
Øystein Grøvlen
Pushed to mysql-next-mr-bugfixing with revision id oystein.grovlen@sun.com-20100527064644-diqyhckwybeb56bd
[15 Jun 2010 8:33]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[4 Aug 2010 8:07]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:18)
[4 Aug 2010 8:23]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:18)
[13 Aug 2010 2:15]
Paul DuBois
Noted in 5.6.0 changelog. Subquery execution for EXPLAIN could be done incorrectly and raise an assertion.