[MDEV-17215] Assertion `rw_lock_own(dict_operation_lock, RW_LOCK_S) || node->vcol_info.is_used()' failed in row0purge.cc:140: bool row_purge_remove_clust_if_poss_low after crash recovery with virtual columns Created: 2018-09-17  Updated: 2018-10-18  Resolved: 2018-10-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.3.11, 10.2.19

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: affects-tests

Attachments: File data-mdev17215.tar.gz     File ib_logfiles-mdev17215.tar.gz     File logs-mdev17215.tar.gz     HTML File threads    
Issue Links:
Relates
relates to MDEV-17218 Assertion `rw_lock_own(dict_operation... Closed

 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



 Comments   
Comment by Marko Mäkelä [ 2018-10-01 ]

Looks OK to me. I only had some minor suggestions.

Generated at Thu Feb 08 08:34:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.