Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL)
Description
|
10.2 654b587999456 |
mysqld: /data/src/10.2/storage/innobase/row/row0purge.cc:140: bool row_purge_remove_clust_if_poss_low(purge_node_t*, ulint): Assertion `rw_lock_own(dict_operation_lock, RW_LOCK_S) || node->vcol_info.is_used()' failed.
|
180921 18:18:09 [ERROR] mysqld got signal 6 ;
|
 |
#7 0x00007f79cc0a0ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#8 0x0000563b59eb0067 in row_purge_remove_clust_if_poss_low (node=0x563b5d747f00, mode=2) at /data/src/10.2/storage/innobase/row/row0purge.cc:139
|
#9 0x0000563b59eb03cd in row_purge_remove_clust_if_poss (node=0x563b5d747f00) at /data/src/10.2/storage/innobase/row/row0purge.cc:216
|
#10 0x0000563b59eb1acf in row_purge_del_mark (node=0x563b5d747f00) at /data/src/10.2/storage/innobase/row/row0purge.cc:799
|
#11 0x0000563b59eb2656 in row_purge_record_func (node=0x563b5d747f00, undo_rec=0x563b5d7483d8 "\016}\016", thr=0x563b5d747e48, updated_extern=false) at /data/src/10.2/storage/innobase/row/row0purge.cc:1093
|
#12 0x0000563b59eb28cd in row_purge (node=0x563b5d747f00, undo_rec=0x563b5d7483d8 "\016}\016", thr=0x563b5d747e48) at /data/src/10.2/storage/innobase/row/row0purge.cc:1154
|
#13 0x0000563b59eb2c0c in row_purge_step (thr=0x563b5d747e48) at /data/src/10.2/storage/innobase/row/row0purge.cc:1240
|
#14 0x0000563b59e441f7 in que_thr_step (thr=0x563b5d747e48) at /data/src/10.2/storage/innobase/que/que0que.cc:1049
|
#15 0x0000563b59e443f5 in que_run_threads_low (thr=0x563b5d747e48) at /data/src/10.2/storage/innobase/que/que0que.cc:1111
|
#16 0x0000563b59e4459e in que_run_threads (thr=0x563b5d747e48) at /data/src/10.2/storage/innobase/que/que0que.cc:1151
|
#17 0x0000563b59efea71 in srv_task_execute () at /data/src/10.2/storage/innobase/srv/srv0srv.cc:2535
|
#18 0x0000563b59efebbf in srv_worker_thread (arg=0x0) at /data/src/10.2/storage/innobase/srv/srv0srv.cc:2582
|
#19 0x00007f79cdd77494 in start_thread (arg=0x7f79897fa700) at pthread_create.c:333
|
#20 0x00007f79cc15d93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
To reproduce:
- download the attached files data-mdev17215.tar.gz
and ib_logfiles-mdev17215.tar.gz; - remove a directory named data if exists in the current folder;
- untar data-mdev17215.tar.gz, it will create data folder with some contents in it;
- untar ib_logfiles-mdev17215.tar.gz, it will put ib_logfiles into the datadir created on the previous step (they are packed separately to fit into 10M attachment limitation in JIRA);
- start 10.2 server on the created datadir data. All default options will do.
The server starts all right, but in a few seconds it aborts with the assertion above.
The attached datadir was created on the same version/build of MariaDB server, by creating tables with virtual columns, performing some DML on them and at some point killing the server with SIGKILL. The datadir was stored after that, before any attempt to restart the server. Full general log and error log from the beginning up to SIGKILL can be found in logs-mdev17215.tar.gz.
All threads' stack trace is also attached.
In case we need to re-create the whole scenario:
|
github.com/MariaDB/randgen --branch elenst-mdev14046 1348571d03a |
perl ./runall-trials.pl --grammar=conf/mariadb/oltp-transactional.yy --grammar2=conf/mariadb/oltp_and_ddl.yy --skip-gendata --gendata-advanced --vcols --scenario=CrashUpgrade --duration=90 --basedir=/data/bld/10.3 --no-mask --seed=1537184920 --threads=4 --queries=100M --mysqld=--loose-max-statement-time=20 --mysqld=--loose-lock-wait-timeout=20 --mysqld=--loose-innodb-lock-wait-timeout=10 --vardir1=/dev/shm/vardir --trials=5
|
Attachments
Issue Links
- relates to
-
-
- Closed
-