[MDEV-21342] Assertion in set_ok_status() upon spatial field error on system-versioned table - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.3.23, 10.4.13, 10.5.3
Component/s: Optimizer, Versioned Tables
Labels:
- regression

Description

Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon erroneous update on system-versioned table

CREATE TABLE t1 (f POINT, KEY(f)) WITH SYSTEM VERSIONING;

--error ER_CANT_CREATE_GEOMETRY_OBJECT

UPDATE t1 SET f = NULL WHERE f = 'foo';

# Cleanup

DROP TABLE t1;

10.3 59a08874
mysqld: /data/src/10.3/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() \|\| (m_status == DA_OK_BULK && is_bulk_op())' failed.
191217 19:49:06 [ERROR] mysqld got signal 6 ;

#7 0x00007f1673eaef12 in __GI___assert_fail (assertion=0x555c0a7e2dc8 "!is_set() \|\| (m_status == DA_OK_BULK && is_bulk_op())", file=0x555c0a7e2d10 "/data/src/10.3/sql/sql_error.cc", line=335, function=0x555c0a7e30c0 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char)") at assert.c:101
#8 0x0000555c09b466ba in Diagnostics_area::set_ok_status (this=0x7f165c006088, affected_rows=0, last_insert_id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_error.cc:335
#9 0x0000555c09af1876 in my_ok (thd=0x7f165c000af0, affected_rows_arg=0, id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_class.h:4892
#10 0x0000555c09c97605 in mysql_update (thd=0x7f165c000af0, table_list=0x7f165c012910, fields=..., values=..., conds=0x7f165c013a80, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f166e0acf10, updated_return=0x7f166e0acfd0) at /data/src/10.3/sql/sql_update.cc:1189
#11 0x0000555c09b93231 in mysql_execute_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:4301
#12 0x0000555c09b9f2a5 in mysql_parse (thd=0x7f165c000af0, rawbuf=0x7f165c012818 "UPDATE t1 SET f = NULL WHERE f = 'foo'", length=38, parser_state=0x7f166e0ad5e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7818
#13 0x0000555c09b8bdf1 in dispatch_command (command=COM_QUERY, thd=0x7f165c000af0, packet=0x7f165c123431 "UPDATE t1 SET f = NULL WHERE f = 'foo'", packet_length=38, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
#14 0x0000555c09b8a739 in do_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
#15 0x0000555c09d01fc2 in do_handle_one_connection (connect=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1403
#16 0x0000555c09d01d24 in handle_one_connection (arg=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1308
#17 0x0000555c0a6af6ca in pfs_spawn_thread (arg=0x555c0dc379c0) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#18 0x00007f1675a244a4 in start_thread (arg=0x7f166e0ae700) at pthread_create.c:456
#19 0x00007f1673f6bd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.3-10.5.
The test case started causing an assertion failure some time between revisions 3d4a8015 and 3466b47b, however there was a similar failure with application periods before, ~~MDEV-20663~~.
No obvious problem on a non-debug build.

Attachments

Issue Links

relates to

MDEV-20663 Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon UPDATE on app-versioned table

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2019-12-17 17:53

Elena Stepanova made changes - 2019-12-17 17:53

Field	Original Value	New Value
Link		This issue relates to ~~MDEV-20663~~ [ ~~MDEV-20663~~ ]

Aleksey Midenkov made changes - 2020-03-13 10:01

Status

Open [ 1 ]

In Progress [ 3 ]

Aleksey Midenkov made changes - 2020-03-13 10:02

Description

{code:sql}
CREATE TABLE t1 (f POINT, KEY(f)) WITH SYSTEM VERSIONING;
--error ER_CANT_CREATE_GEOMETRY_OBJECT
UPDATE t1 SET f = NULL WHERE f = 'foo';

# Cleanup
DROP TABLE t1;
{code}

{noformat:title=10.3 59a08874}
mysqld: /data/src/10.3/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
191217 19:49:06 [ERROR] mysqld got signal 6 ;

#7 0x00007f1673eaef12 in __GI___assert_fail (assertion=0x555c0a7e2dc8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x555c0a7e2d10 "/data/src/10.3/sql/sql_error.cc", line=335, function=0x555c0a7e30c0 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8 0x0000555c09b466ba in Diagnostics_area::set_ok_status (this=0x7f165c006088, affected_rows=0, last_insert_id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_error.cc:335
#9 0x0000555c09af1876 in my_ok (thd=0x7f165c000af0, affected_rows_arg=0, id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_class.h:4892
#10 0x0000555c09c97605 in mysql_update (thd=0x7f165c000af0, table_list=0x7f165c012910, fields=..., values=..., conds=0x7f165c013a80, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f166e0acf10, updated_return=0x7f166e0acfd0) at /data/src/10.3/sql/sql_update.cc:1189
#11 0x0000555c09b93231 in mysql_execute_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:4301
#12 0x0000555c09b9f2a5 in mysql_parse (thd=0x7f165c000af0, rawbuf=0x7f165c012818 "UPDATE t1 SET f = NULL WHERE f = 'foo'", length=38, parser_state=0x7f166e0ad5e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7818
#13 0x0000555c09b8bdf1 in dispatch_command (command=COM_QUERY, thd=0x7f165c000af0, packet=0x7f165c123431 "UPDATE t1 SET f = NULL WHERE f = 'foo'", packet_length=38, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
#14 0x0000555c09b8a739 in do_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
#15 0x0000555c09d01fc2 in do_handle_one_connection (connect=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1403
#16 0x0000555c09d01d24 in handle_one_connection (arg=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1308
#17 0x0000555c0a6af6ca in pfs_spawn_thread (arg=0x555c0dc379c0) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#18 0x00007f1675a244a4 in start_thread (arg=0x7f166e0ae700) at pthread_create.c:456
#19 0x00007f1673f6bd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}

Reproducible on 10.3-10.5.
The test case started causing an assertion failure some time between revisions 3d4a8015 and 3466b47b, however there was a similar failure with application periods before, ~~MDEV-20663~~.
No obvious problem on a non-debug build.

Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon erroneous update on system-versioned table

{code:sql}
CREATE TABLE t1 (f POINT, KEY(f)) WITH SYSTEM VERSIONING;
--error ER_CANT_CREATE_GEOMETRY_OBJECT
UPDATE t1 SET f = NULL WHERE f = 'foo';

# Cleanup
DROP TABLE t1;
{code}

{noformat:title=10.3 59a08874}
mysqld: /data/src/10.3/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
191217 19:49:06 [ERROR] mysqld got signal 6 ;

#7 0x00007f1673eaef12 in __GI___assert_fail (assertion=0x555c0a7e2dc8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x555c0a7e2d10 "/data/src/10.3/sql/sql_error.cc", line=335, function=0x555c0a7e30c0 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8 0x0000555c09b466ba in Diagnostics_area::set_ok_status (this=0x7f165c006088, affected_rows=0, last_insert_id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_error.cc:335
#9 0x0000555c09af1876 in my_ok (thd=0x7f165c000af0, affected_rows_arg=0, id=0, message=0x7f166e0aca90 "Rows matched: 0 Changed: 0 Inserted: 0 Warnings: 1") at /data/src/10.3/sql/sql_class.h:4892
#10 0x0000555c09c97605 in mysql_update (thd=0x7f165c000af0, table_list=0x7f165c012910, fields=..., values=..., conds=0x7f165c013a80, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f166e0acf10, updated_return=0x7f166e0acfd0) at /data/src/10.3/sql/sql_update.cc:1189
#11 0x0000555c09b93231 in mysql_execute_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:4301
#12 0x0000555c09b9f2a5 in mysql_parse (thd=0x7f165c000af0, rawbuf=0x7f165c012818 "UPDATE t1 SET f = NULL WHERE f = 'foo'", length=38, parser_state=0x7f166e0ad5e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7818
#13 0x0000555c09b8bdf1 in dispatch_command (command=COM_QUERY, thd=0x7f165c000af0, packet=0x7f165c123431 "UPDATE t1 SET f = NULL WHERE f = 'foo'", packet_length=38, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
#14 0x0000555c09b8a739 in do_command (thd=0x7f165c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
#15 0x0000555c09d01fc2 in do_handle_one_connection (connect=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1403
#16 0x0000555c09d01d24 in handle_one_connection (arg=0x555c0dc1ca00) at /data/src/10.3/sql/sql_connect.cc:1308
#17 0x0000555c0a6af6ca in pfs_spawn_thread (arg=0x555c0dc379c0) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#18 0x00007f1675a244a4 in start_thread (arg=0x7f166e0ae700) at pthread_create.c:456
#19 0x00007f1673f6bd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}

Reproducible on 10.3-10.5.
The test case started causing an assertion failure some time between revisions 3d4a8015 and 3466b47b, however there was a similar failure with application periods before, ~~MDEV-20663~~.
No obvious problem on a non-debug build.

Aleksey Midenkov made changes - 2020-03-13 10:02

Component/s

Optimizer [ 10200 ]

Aleksey Midenkov made changes - 2020-03-13 10:05

Summary

Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon erroneous update on system-versioned table

Assertion in set_ok_status() upon spatial field error on system-versioned table

Aleksey Midenkov made changes - 2020-03-17 08:14

Assignee	Aleksey Midenkov [ midenok ]	Oleksandr Byelkin [ sanja ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Oleksandr Byelkin added a comment - 2020-03-17 08:17

OK to push!

Oleksandr Byelkin added a comment - 2020-03-17 08:17 OK to push!

Aleksey Midenkov made changes - 2020-03-18 13:54

Assignee

Oleksandr Byelkin [ sanja ]

Aleksey Midenkov [ midenok ]

Aleksey Midenkov made changes - 2020-03-18 13:54

Status

In Review [ 10002 ]

Stalled [ 10000 ]

Aleksey Midenkov made changes - 2020-03-18 13:54

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Aleksey Midenkov made changes - 2020-04-02 21:50

Fix Version/s		10.3.23 [ 24222 ]
Fix Version/s		10.4.13 [ 24223 ]
Fix Version/s		10.5.3 [ 24263 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Fixed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:50

Workflow

MariaDB v3 [ 102519 ]

MariaDB v4 [ 157114 ]

People

Assignee:: Aleksey Midenkov

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: 2019-12-17 17:53

Updated:: 2020-04-02 21:50

Resolved:: 2020-04-02 21:50

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration