[MDEV-5628] Assertion `! is_set()' or `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' fails on UPDATE on a partitioned table with subquery (MySQL:71630) Created: 2014-02-07  Updated: 2020-10-20  Resolved: 2020-10-20

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Partitioning
Affects Version/s: 5.1.67, 5.2.14, 5.5.35, 10.0.8, 5.5, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.1.48, 10.2.35, 10.3.26, 10.4.16, 10.5.7

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Rucha Deodhar
Resolution: Fixed Votes: 0
Labels: affects-tests, upstream-fixed

Issue Links:
Duplicate
duplicates MDEV-11779 Assertion `!is_set() || (m_status == ... Closed
duplicates MDEV-17537 [Draft] Assertion `! is_set()' failed... Closed
Relates
relates to MDEV-22783 Assertion `!is_set() || (m_status == ... Confirmed

 Description    

--source include/have_partition.inc
 
 
 
CREATE TABLE t1 (a INT) PARTITION BY HASH(a) PARTITIONS 2;
 
 
 
CREATE TABLE t2 (b INT);
 
INSERT INTO t2 VALUES (1),(2);
 
 
 
UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6;

On some reason, it does not fail on 5.3, but fails on 5.1, 5.2, 5.5 and 10.0 (and on all current branches of MySQL).

Stack trace from 5.5:

mysqld: 5.5/sql/sql_error.cc:362: void Diagnostics_area::set_ok_status(THD*, ulonglong, ulonglong, const char*): Assertion `! is_set()' failed.
 
140207 23:42:49 [ERROR] mysqld got signal 6 ;


#6  0x00007f84cb4bb621 in *__GI___assert_fail (assertion=0xd68c86 "! is_set()", file=<optimized out>, line=362, function=0xd69740 "void Diagnostics_area::set_ok_status(THD*, ulonglong, ulonglong, const char*)") at assert.c:81
 
#7  0x000000000060c8b5 in Diagnostics_area::set_ok_status (this=0x7f84c7ff26a0, thd=0x7f84c7fee060, affected_rows_arg=0, last_insert_id_arg=0, message_arg=0x0) at 5.5/sql/sql_error.cc:362
 
#8  0x00000000005c9d70 in my_ok (thd=0x7f84c7fee060, affected_rows=0, id=0, message=0x0) at 5.5/sql/sql_class.h:3168
 
#9  0x00000000006e1ce7 in mysql_update (thd=0x7f84c7fee060, table_list=0x7f84c615d1b0, fields=..., values=..., conds=0x7f84c615ed48, order_num=1, order=0x7f84c615efc0, limit=6, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f84c6bb5298, updated_return=0x7f84c6bb5290) at 5.5/sql/sql_update.cc:401
 
#10 0x0000000000630ea1 in mysql_execute_command (thd=0x7f84c7fee060) at 5.5/sql/sql_parse.cc:2847
 
#11 0x0000000000638cf6 in mysql_parse (thd=0x7f84c7fee060, rawbuf=0x7f84c615d078 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", length=69, parser_state=0x7f84c6bb5630) at 5.5/sql/sql_parse.cc:5799
 
#12 0x000000000062cd17 in dispatch_command (command=COM_QUERY, thd=0x7f84c7fee060, packet=0x7f84c72ff061 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", packet_length=69) at 5.5/sql/sql_parse.cc:1078
 
#13 0x000000000062beba in do_command (thd=0x7f84c7fee060) at 5.5/sql/sql_parse.cc:793
 
#14 0x000000000072d982 in do_handle_one_connection (thd_arg=0x7f84c7fee060) at 5.5/sql/sql_connect.cc:1266
 
#15 0x000000000072d441 in handle_one_connection (arg=0x7f84c7fee060) at 5.5/sql/sql_connect.cc:1181
 
#16 0x000000000098592d in pfs_spawn_thread (arg=0x7f84c7ff59e0) at 5.5/storage/perfschema/pfs.cc:1015
 
#17 0x00007f84cca1bb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#18 0x00007f84cb56aa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112


revision-id: elenst@wheezy-64.home-20140205102537-7ern5gfca6a6ojg3
 
revno: 4055
 
branch-nick: 5.5



 Comments   
Comment by Elena Stepanova [ 2018-06-10 ]

Still reproducible on all of MariaDB 5.5-10.3 and MySQL 5.6. Not reproducible on MySQL 5.7, although the public bug report does not show any signs of the bug being fixed; so, I'm changing the tag to upstream-fixed._

10.1 3627dd7f6a

 
mysqld: /data/src/10.1/sql/sql_error.cc:378: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `! is_set()' failed.
 
180610 17:43:22 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007faeb85a3ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x00005593bc128206 in Diagnostics_area::set_ok_status (this=0x7faeb14da008, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.1/sql/sql_error.cc:378
 
#9  0x00005593bc0e0c97 in my_ok (thd=0x7faeb14d5070, affected_rows=0, id=0, message=0x0) at /data/src/10.1/sql/sql_class.h:4180
 
#10 0x00005593bc22d5cd in mysql_update (thd=0x7faeb14d5070, table_list=0x7faeaf8431c0, fields=..., values=..., conds=0x7faeaf844de0, order_num=1, order=0x7faeaf845048, limit=6, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7faeba626cc0, updated_return=0x7faeba626d50) at /data/src/10.1/sql/sql_update.cc:415
 
#11 0x00005593bc15394c in mysql_execute_command (thd=0x7faeb14d5070) at /data/src/10.1/sql/sql_parse.cc:3785
 
#12 0x00005593bc15ec75 in mysql_parse (thd=0x7faeb14d5070, rawbuf=0x7faeaf843088 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", length=69, parser_state=0x7faeba6275e0) at /data/src/10.1/sql/sql_parse.cc:7449
 
#13 0x00005593bc14d69d in dispatch_command (command=COM_QUERY, thd=0x7faeb14d5070, packet=0x7faeb3ff9071 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", packet_length=69) at /data/src/10.1/sql/sql_parse.cc:1492
 
#14 0x00005593bc14c422 in do_command (thd=0x7faeb14d5070) at /data/src/10.1/sql/sql_parse.cc:1121
 
#15 0x00005593bc285afd in do_handle_one_connection (thd_arg=0x7faeb14d5070) at /data/src/10.1/sql/sql_connect.cc:1330
 
#16 0x00005593bc285861 in handle_one_connection (arg=0x7faeb14d5070) at /data/src/10.1/sql/sql_connect.cc:1242
 
#17 0x00005593bc641f04 in pfs_spawn_thread (arg=0x7faeb7c3a170) at /data/src/10.1/storage/perfschema/pfs.cc:1861
 
#18 0x00007faeba2a7494 in start_thread (arg=0x7faeba628b00) at pthread_create.c:333
 
#19 0x00007faeb866093f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Note: whoever ends up fixing it (if anyone, ever), feel free to fix in an earlier version than Fix Versions fields indicates.

Comment by Sachin Setiya (Inactive) [ 2018-09-06 ]

bb-5.5-5628

Comment by Elena Stepanova [ 2018-09-23 ]

On 10.2+ the assertion is slightly different, as usual:

mysqld: /data/src/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
 
180923 18:37:25 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007ff23149cee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x0000559e522c9a2d in Diagnostics_area::set_ok_status (this=0x7ff210005cd8, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.2/sql/sql_error.cc:380
 
#9  0x0000559e5227c077 in my_ok (thd=0x7ff210000b00, affected_rows=0, id=0, message=0x0) at /data/src/10.2/sql/sql_class.h:4506
 
#10 0x0000559e523e3c74 in mysql_update (thd=0x7ff210000b00, table_list=0x7ff2100125c0, fields=..., values=..., conds=0x7ff2100142f8, order_num=1, order=0x7ff210014560, limit=6, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7ff227768860, updated_return=0x7ff227768910) at /data/src/10.2/sql/sql_update.cc:407
 
#11 0x0000559e522f8d31 in mysql_execute_command (thd=0x7ff210000b00) at /data/src/10.2/sql/sql_parse.cc:4290
 
#12 0x0000559e5230487f in mysql_parse (thd=0x7ff210000b00, rawbuf=0x7ff210012488 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", length=69, parser_state=0x7ff227769200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8011
 
#13 0x0000559e522f21da in dispatch_command (command=COM_QUERY, thd=0x7ff210000b00, packet=0x7ff21008c1a1 "UPDATE t1 SET a = 7 WHERE a = ( SELECT b FROM t2 ) ORDER BY a LIMIT 6", packet_length=69, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
 
#14 0x0000559e522f0b3d in do_command (thd=0x7ff210000b00) at /data/src/10.2/sql/sql_parse.cc:1378
 
#15 0x0000559e52442b4e in do_handle_one_connection (connect=0x559e55241b70) at /data/src/10.2/sql/sql_connect.cc:1335
 
#16 0x0000559e524428db in handle_one_connection (arg=0x559e55241b70) at /data/src/10.2/sql/sql_connect.cc:1241
 
#17 0x0000559e52866aa8 in pfs_spawn_thread (arg=0x559e551a52d0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
 
#18 0x00007ff233173494 in start_thread (arg=0x7ff22776a700) at pthread_create.c:333
 
#19 0x00007ff23155993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Sachin Setiya (Inactive) [ 2018-10-13 ]

Hi elenst!
The patch works for 10.2 also

Comment by Oleksandr Byelkin [ 2018-11-07 ]

I do not see the commit to review.

Comment by Sachin Setiya (Inactive) [ 2018-11-08 ]

sanja this commit -> https://github.com/MariaDB/server/commit/d9751996415e2ba0e7d3bd388f223abad2df6c09 it is on bb-5.5-5628 branch

Comment by Oleksandr Byelkin [ 2018-11-08 ]

As we discussed, place where error lost should be found

Comment by Sergei Golubchik [ 2020-10-18 ]

ok to push

Generated at Thu Feb 08 07:05:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.