Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
Note: The test case uses system versioning, so it's only applicable to 10.3+. I don't see why it would be specific to versioning, but I couldn't get rid of it using standard tricks.
--source include/have_innodb.inc
|
|
|
CREATE TABLE t1 ( |
pk int, |
f1 char(8), |
f2 char(8), |
f3 char(8), |
f4 char(8), |
f5 char(8), |
PRIMARY KEY (pk), |
KEY (f3), |
FULLTEXT (f5),
|
FOREIGN KEY (f2) REFERENCES t1 (f3) ON DELETE SET NULL |
) CHARSET utf8 ENGINE=InnoDB WITH SYSTEM VERSIONING; |
|
|
INSERT INTO t1 VALUES |
(1,'','','','','') , |
(2,'','','','"bar"',''), |
(3,'','','','',''); |
|
|
DELETE FROM t1 WHERE pk = 1; |
UPDATE t1 SET f1 = 'bar'; |
ALTER TABLE t1 ADD FULLTEXT (f4); |
|
|
# Cleanup
|
DROP TABLE t1; |
|
10.3 450c017c |
mysqld: /data/src/10.3/storage/innobase/fts/fts0fts.cc:1268: void fts_cache_node_add_positions(fts_cache_t*, fts_node_t*, doc_id_t, ib_vector_t*): Assertion `last_pos == 0 || pos > last_pos' failed.
|
210417 18:41:40 [ERROR] mysqld got signal 6 ;
|
|
|
#3 <signal handler called>
|
#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
|
#5 0x00007f46ee91c859 in __GI_abort () at abort.c:79
|
#6 0x00007f46ee91c729 in __assert_fail_base (fmt=0x7f46eeab2588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x561370ac4788 "last_pos == 0 || pos > last_pos", file=0x561370ac40d0 "/data/src/10.3/storage/innobase/fts/fts0fts.cc", line=1268, function=<optimized out>) at assert.c:92
|
#7 0x00007f46ee92df36 in __GI___assert_fail (assertion=0x561370ac4788 "last_pos == 0 || pos > last_pos", file=0x561370ac40d0 "/data/src/10.3/storage/innobase/fts/fts0fts.cc", line=1268, function=0x561370ac4710 "void fts_cache_node_add_positions(fts_cache_t*, fts_node_t*, doc_id_t, ib_vector_t*)") at assert.c:101
|
#8 0x00005613704c885b in fts_cache_node_add_positions (cache=0x0, node=0x7f4694021538, doc_id=2, positions=0x7f4694021618) at /data/src/10.3/storage/innobase/fts/fts0fts.cc:1268
|
#9 0x0000561370225a9b in row_fts_insert_tuple (ins_ctx=0x7f46aaffc9b0, word=0x7f46aaffc990, positions=0x7f4694021618, in_doc_id=0x7f46aaffc8c8, dtuple=0x7f4694010ff0) at /data/src/10.3/storage/innobase/row/row0ftsort.cc:1356
|
#10 0x000056137022706f in row_fts_merge_insert (index=0x7f46900b7cf0, table=0x7f4690163860, psort_info=0x7f469003cd40, id=1) at /data/src/10.3/storage/innobase/row/row0ftsort.cc:1774
|
#11 0x0000561370225183 in fts_parallel_merge (arg=0x7f4690050600) at /data/src/10.3/storage/innobase/row/row0ftsort.cc:1112
|
#12 0x00007f46eee3d609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#13 0x00007f46eea19293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Reproducible on 10.3-10.6 (10.2 is out of scope because of versioning).
No obvious immediate problem on a non-debug build.
Possibly related to MDEV-24088, despite not having simple_parser. I think the earlier dirty test cases here were even triggering a stack trace more resembling MDEV-24088, and I was preparing it as a comment to MDEV-24088, but they diverged at the end, so I decided to file it separately instead.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-