[MDEV-22564] Assertion `marked_for_write_or_computed()' failed in Field_long::store upon UPDATE on system- and app-versioned table Created: 2020-05-14  Updated: 2021-10-04  Resolved: 2021-10-04

Status: Closed
Project: MariaDB Server
Component/s: Versioned Tables
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4.19, 10.5.10

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: affects-tests

Issue Links:
Blocks
Relates
relates to MDEV-21812 Assertion `marked_for_write_or_comput... Confirmed
relates to MDEV-22414 UPDATE or DELETE FOR PORTION OF incre... Closed
relates to MDEV-22562 Assertion `next_insert_id == 0' upon ... Closed

 Description   

Note: Possibly related to or even caused by MDEV-22414.

CREATE TABLE t1 (id INT AUTO_INCREMENT, f VARCHAR(16), s DATE, e DATE, PERIOD FOR p(s,e), PRIMARY KEY(id)) WITH SYSTEM VERSIONING;
INSERT INTO t1 VALUES (1,NULL,'1973-07-30','2008-03-11'), (2,NULL,'1998-12-22','2037-11-05');
UPDATE IGNORE t1 SET id = NULL;
UPDATE t1 FOR PORTION OF p FROM '1998-08-17' TO '1998-09-19' SET f = NULL;
UPDATE t1 SET f = 'k';
 
# Cleanup
DROP TABLE t1;

10.4 38f6c47f

mysqld: /data/src/10.4/sql/field.cc:4238: virtual int Field_long::store(longlong, bool): Assertion `marked_for_write_or_computed()' failed.
200514 21:21:07 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f9414dfef12 in __GI___assert_fail (assertion=0x557f8eb93b30 "marked_for_write_or_computed()", file=0x557f8eb9388b "/data/src/10.4/sql/field.cc", line=4238, function=0x557f8eb96280 <Field_long::store(long long, bool)::__PRETTY_FUNCTION__> "virtual int Field_long::store(longlong, bool)") at assert.c:101
#8  0x0000557f8e0213e1 in Field_long::store (this=0x7f93f4132db8, nr=5, unsigned_val=true) at /data/src/10.4/sql/field.cc:4238
#9  0x0000557f8e05c2dc in handler::update_auto_increment (this=0x7f93f412a318) at /data/src/10.4/sql/handler.cc:3431
#10 0x0000557f8e7d486a in ha_myisam::write_row (this=0x7f93f412a318, buf=0x7f93f4132cf0 "\377") at /data/src/10.4/storage/myisam/ha_myisam.cc:946
#11 0x0000557f8e065732 in handler::ha_write_row (this=0x7f93f412a318, buf=0x7f93f4132cf0 "\377") at /data/src/10.4/sql/handler.cc:6706
#12 0x0000557f8dcb4c47 in vers_insert_history_row (table=0x7f93f400ae20) at /data/src/10.4/sql/sql_insert.cc:1685
#13 0x0000557f8de0e6c2 in mysql_update (thd=0x7f93f4000af0, table_list=0x7f93f4013270, fields=..., values=..., conds=0x7f93f4013fd0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f940af8be40, updated_return=0x7f940af8bf00) at /data/src/10.4/sql/sql_update.cc:1073
#14 0x0000557f8dcffaf3 in mysql_execute_command (thd=0x7f93f4000af0) at /data/src/10.4/sql/sql_parse.cc:4376
#15 0x0000557f8dd0bb4d in mysql_parse (thd=0x7f93f4000af0, rawbuf=0x7f93f4013198 "UPDATE t1 SET f = 'k'", length=21, parser_state=0x7f940af8c570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7900
#16 0x0000557f8dcf80fd in dispatch_command (command=COM_QUERY, thd=0x7f93f4000af0, packet=0x7f93f4136221 "UPDATE t1 SET f = 'k'", packet_length=21, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
#17 0x0000557f8dcf689f in do_command (thd=0x7f93f4000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#18 0x0000557f8de7e458 in do_handle_one_connection (connect=0x557f91e61cf0) at /data/src/10.4/sql/sql_connect.cc:1412
#19 0x0000557f8de7e1a7 in handle_one_connection (arg=0x557f91e61cf0) at /data/src/10.4/sql/sql_connect.cc:1316
#20 0x0000557f8e87e46b in pfs_spawn_thread (arg=0x557f91e7dbf0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#21 0x00007f9416d874a4 in start_thread (arg=0x7f940af8d700) at pthread_create.c:456
#22 0x00007f9414ebbd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.4, 10.5, with at least MyISAM, InnoDB, Aria.
No obvious effect on a non-debug build, other than MDEV-22414.



 Comments   
Comment by Aleksey Midenkov [ 2021-08-19 ]

That doesn't reproduce for me on 38f6c47f8a0a9bc313e4875c4676985249771c76 or on latest head 89723ce17959d61a993136e51104fc9b830ac67c

Comment by Elena Stepanova [ 2021-10-04 ]

It is reproducible on 38f6c47f8a0 all right (it always fails for me, but still maybe it is in some way non-deterministic, we've seen it happen before).
Indeed not reproducible on latest 10.4. It disappeared after this merge:

commit 5008171b05e0d3b8b5f4af312b94a312281e77c7
Merge: 61f84bba603 13d06417108
Author: Marko Mäkelä <marko.makela@mariadb.com>
Date:   Wed Apr 14 10:33:59 2021 +0300
 
    Merge 10.3 into 10.4

particularly after this commt:

commit 0c99e6e9a6a5a64b0d757d796ab53d361e7fb001
Author: Aleksey Midenkov <midenok@gmail.com>
Date:   Sun Feb 14 23:26:12 2021 +0300
 
    MDEV-22562 Assertion `next_insert_id == 0' upon UPDATE on system-versioned table
    
    Don't update autoinc counter on history row insert. Uniqueness is kept
    due to merge with row_end.

It looks quite related, so I guess it's all right to close it as a duplicate of MDEV-22562.

Generated at Thu Feb 08 09:15:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.