[MDEV-5405] RQG induced crash in mi_assign_to_key_cache in safe mutex unlock - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 5.3.12, 5.5.34, 10.0.6
Fix Version/s: 5.5.35, 10.0.8
Component/s: None
Labels:
None
Environment:
centos 6.2 running a debug build of mariadb-5.5.34

Description

When running this RQG test:

./runall.pl --grammar=conf/partitioning/partitions-99-hash.yy --duration=300 --queries=100000000 --threads=64 --basedir=/home/prohaska/mariadb-5.5.34-install/ --vardir=/home/prohaska/vardir.part99.3 --mask-level=0 --mask=0 --seed=1 --mysqld=--general_log --sqltrace

The code hits an assert in safe_mutex_unlock. With this code in mi_keycache.c that i added:

  lock = &share->key_cache->op_lock;

  pthread_mutex_lock(&share->key_cache->op_lock);

  if (flush_key_blocks(share->key_cache, share->kfile, &share->dirty_part_map,

                       FLUSH_RELEASE))

    error= my_errno;

    mi_print_error(info->s, HA_ERR_CRASHED);

    mi_mark_crashed(info);              /* Mark that table must be checked */

=>assert(lock == &share->key_cache->op_lock);

  pthread_mutex_unlock(&share->key_cache->op_lock);

Hits the assert since some other thread probably changed the share->key_cache pointer:

#8  0x0000000000c3988a in mi_assign_to_key_cache (info=0x7fb600b1ba60, key_map=1, key_cache=0x7fb60c83ebe0) at /home/prohaska/mariadb-5.5.34/storage/myisam/mi_keycache.c:89

#9  0x0000000000c147ff in ha_myisam::assign_to_keycache (this=0x7fb6005d3e78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/storage/myisam/ha_myisam.cc:1237

#10 0x0000000000c752a5 in ha_partition::handle_opt_part (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, part_id=5, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1084

#11 0x0000000000c75978 in ha_partition::handle_opt_partitions (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1239

#12 0x0000000000c75083 in ha_partition::assign_to_keycache (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1011

#13 0x00000000007159c0 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, \

TABLE_LIST *)) (thd=0x7fb5f194c060, tables=0x7fb5f11da168, check_opt=0x7fb5efb22ce0, operator_name=0xd7efcd "assign_to_keycache", lock_type=TL_READ_NO_INSERT, open_for_modify=false, repair_table_use_frm=\

false, extra_open_options=0, prepare_func=0x0, operator_func=&virtual table offset 504, view_operator_func=0x0) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:649

#14 0x0000000000716c27 in mysql_assign_to_keycache (thd=0x7fb5f194c060, tables=0x7fb5f11da168, key_cache_name=0x7fb5f194fe48) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:992

#15 0x000000000060a1dc in mysql_execute_command (thd=0x7fb5f194c060) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:2349

#16 0x00000000006132be in mysql_parse (thd=0x7fb5f194c060, rawbuf=0x7fb5f11da078 "CACHE INDEX i IN c4", length=19, parser_state=0x7fb5efb23650) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:5798

(gdb) p lock

$1 = (void *) 0x7fb622c1e6b0

(gdb) p &share->key_cache->op_lock

$2 = (safe_mutex_t *) 0x7fb5ff8308b0

Attachments

Activity

Ascending order - Click to sort in descending order

Rich Prohaska created issue - 2013-12-06 22:08

Sergei Golubchik made changes - 2013-12-10 18:05

Field	Original Value	New Value
Description	When running this RQG test: ./runall.pl --grammar=conf/partitioning/partitions-99-hash.yy --duration=300 --queries=100000000 --threads=64 --basedir=/home/prohaska/mariadb-5.5.34-install/ --vardir=/home/prohaska/vardir.part99.3 --mask-level=0 --mask=0 --seed=1 --mysqld=--general_log --sqltrace The code hits an assert in safe_mutex_unlock. With this code in mi_keycache.c that i added: lock = &share->key_cache->op_lock; pthread_mutex_lock(&share->key_cache->op_lock); if (flush_key_blocks(share->key_cache, share->kfile, &share->dirty_part_map, FLUSH_RELEASE)) { error= my_errno; mi_print_error(info->s, HA_ERR_CRASHED); mi_mark_crashed(info); /* Mark that table must be checked / } =>assert(lock == &share->key_cache->op_lock); pthread_mutex_unlock(&share->key_cache->op_lock); Hits the assert since some other thread probably changed the share->key_cache pointer: #8 0x0000000000c3988a in mi_assign_to_key_cache (info=0x7fb600b1ba60, key_map=1, key_cache=0x7fb60c83ebe0) at /home/prohaska/mariadb-5.5.34/storage/myisam/mi_keycache.c:89 #9 0x0000000000c147ff in ha_myisam::assign_to_keycache (this=0x7fb6005d3e78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/storage/myisam/ha_myisam.cc:1237 #10 0x0000000000c752a5 in ha_partition::handle_opt_part (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, part_id=5, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1084 #11 0x0000000000c75978 in ha_partition::handle_opt_partitions (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1239 #12 0x0000000000c75083 in ha_partition::assign_to_keycache (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1011 #13 0x00000000007159c0 in mysql_admin_table(THD , TABLE_LIST , HA_CHECK_OPT , const char , thr_lock_type, bool, bool, uint, int ()(THD , TABLE_LIST , HA_CHECK_OPT ), struct {...}, int ()(THD , \ TABLE_LIST )) (thd=0x7fb5f194c060, tables=0x7fb5f11da168, check_opt=0x7fb5efb22ce0, operator_name=0xd7efcd "assign_to_keycache", lock_type=TL_READ_NO_INSERT, open_for_modify=false, repair_table_use_frm=\ false, extra_open_options=0, prepare_func=0x0, operator_func=&virtual table offset 504, view_operator_func=0x0) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:649 #14 0x0000000000716c27 in mysql_assign_to_keycache (thd=0x7fb5f194c060, tables=0x7fb5f11da168, key_cache_name=0x7fb5f194fe48) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:992 #15 0x000000000060a1dc in mysql_execute_command (thd=0x7fb5f194c060) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:2349 #16 0x00000000006132be in mysql_parse (thd=0x7fb5f194c060, rawbuf=0x7fb5f11da078 "CACHE INDEX i IN c4", length=19, parser_state=0x7fb5efb23650) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:5798 (gdb) p lock $1 = (void ) 0x7fb622c1e6b0 (gdb) p &share->key_cache->op_lock $2 = (safe_mutex_t ) 0x7fb5ff8308b0	When running this RQG test: {code} ./runall.pl --grammar=conf/partitioning/partitions-99-hash.yy --duration=300 --queries=100000000 --threads=64 --basedir=/home/prohaska/mariadb-5.5.34-install/ --vardir=/home/prohaska/vardir.part99.3 --mask-level=0 --mask=0 --seed=1 --mysqld=--general_log --sqltrace {code} The code hits an assert in {{safe_mutex_unlock}}. With this code in {{mi_keycache.c}} that i added: {code} lock = &share->key_cache->op_lock; pthread_mutex_lock(&share->key_cache->op_lock); if (flush_key_blocks(share->key_cache, share->kfile, &share->dirty_part_map, FLUSH_RELEASE)) { error= my_errno; mi_print_error(info->s, HA_ERR_CRASHED); mi_mark_crashed(info); /* Mark that table must be checked / } =>assert(lock == &share->key_cache->op_lock); pthread_mutex_unlock(&share->key_cache->op_lock); {code} Hits the assert since some other thread probably changed the share->key_cache pointer: {noformat} #8 0x0000000000c3988a in mi_assign_to_key_cache (info=0x7fb600b1ba60, key_map=1, key_cache=0x7fb60c83ebe0) at /home/prohaska/mariadb-5.5.34/storage/myisam/mi_keycache.c:89 #9 0x0000000000c147ff in ha_myisam::assign_to_keycache (this=0x7fb6005d3e78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/storage/myisam/ha_myisam.cc:1237 #10 0x0000000000c752a5 in ha_partition::handle_opt_part (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, part_id=5, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1084 #11 0x0000000000c75978 in ha_partition::handle_opt_partitions (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0, flag=5) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1239 #12 0x0000000000c75083 in ha_partition::assign_to_keycache (this=0x7fb5f66ffa78, thd=0x7fb5f194c060, check_opt=0x7fb5efb22ce0) at /home/prohaska/mariadb-5.5.34/sql/ha_partition.cc:1011 #13 0x00000000007159c0 in mysql_admin_table(THD , TABLE_LIST , HA_CHECK_OPT , const char , thr_lock_type, bool, bool, uint, int ()(THD , TABLE_LIST , HA_CHECK_OPT ), struct {...}, int ()(THD , \ TABLE_LIST )) (thd=0x7fb5f194c060, tables=0x7fb5f11da168, check_opt=0x7fb5efb22ce0, operator_name=0xd7efcd "assign_to_keycache", lock_type=TL_READ_NO_INSERT, open_for_modify=false, repair_table_use_frm=\ false, extra_open_options=0, prepare_func=0x0, operator_func=&virtual table offset 504, view_operator_func=0x0) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:649 #14 0x0000000000716c27 in mysql_assign_to_keycache (thd=0x7fb5f194c060, tables=0x7fb5f11da168, key_cache_name=0x7fb5f194fe48) at /home/prohaska/mariadb-5.5.34/sql/sql_admin.cc:992 #15 0x000000000060a1dc in mysql_execute_command (thd=0x7fb5f194c060) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:2349 #16 0x00000000006132be in mysql_parse (thd=0x7fb5f194c060, rawbuf=0x7fb5f11da078 "CACHE INDEX i IN c4", length=19, parser_state=0x7fb5efb23650) at /home/prohaska/mariadb-5.5.34/sql/sql_parse.cc:5798 (gdb) p lock $1 = (void ) 0x7fb622c1e6b0 (gdb) p &share->key_cache->op_lock $2 = (safe_mutex_t ) 0x7fb5ff8308b0 {noformat}

Sergei Golubchik made changes - 2013-12-10 18:06

Assignee

Elena Stepanova [ elenst ]

Elena Stepanova made changes - 2013-12-21 01:16

Fix Version/s		10.0.8 [ 14200 ]
Fix Version/s		5.5.35 [ 14000 ]
Fix Version/s		5.3.13 [ 12602 ]
Affects Version/s		10.0.7 [ 14100 ]
Affects Version/s		5.3.13 [ 12602 ]
Assignee	Elena Stepanova [ elenst ]	Alexander Barkov [ bar ]

Elena Stepanova made changes - 2013-12-21 01:18

Comment

[ The problem appeared in 5.3 tree with the following revision:

------------------------------------------------------------
revno: 3674
revision-id: bar@mariadb.org-20130812124759-8cy7ot1s3ysgned2
parent: sanja@montyprogram.com-20130801084611-udozq8c9kxgy94bq
committer: Alexander Barkov <bar@mariadb.org>
branch nick: 5.3.b4652
timestamp: Mon 2013-08-12 16:47:59 +0400
message:
~~MDEV-4652~~ Wrong result for CONCAT(GREATEST(TIME('00:00:01'),TIME('00:00:00'))

###########################

# Test case:

CREATE TABLE t1 (t TIME);
INSERT INTO t1 VALUES ('03:22:30'),('18:30:05');
SELECT CONVERT_TZ( GREATEST( t, CURRENT_DATE() ), 'Europe/Moscow', 'Japan' ) FROM t1;

]

Elena Stepanova made changes - 2013-12-21 01:18

Assignee

Alexander Barkov [ bar ]

Elena Stepanova [ elenst ]

Elena Stepanova made changes - 2013-12-21 01:18

Fix Version/s	5.3.13 [ 12602 ]
Fix Version/s	5.5.35 [ 14000 ]
Fix Version/s	10.0.8 [ 14200 ]

Elena Stepanova made changes - 2013-12-21 01:19

Affects Version/s	5.3.13 [ 12602 ]
Affects Version/s	10.0.7 [ 14100 ]

Elena Stepanova made changes - 2013-12-25 20:29

Affects Version/s		5.3.12 [ 12000 ]
Affects Version/s		10.0.6 [ 13202 ]
Assignee	Elena Stepanova [ elenst ]	Sergei Golubchik [ serg ]

Elena Stepanova made changes - 2013-12-25 20:51

Fix Version/s		10.0.7 [ 14100 ]
Fix Version/s		5.5.35 [ 14000 ]
Fix Version/s		5.3.13 [ 12602 ]

Sergei Golubchik made changes - 2013-12-28 17:50

Fix Version/s		10.0.8 [ 14200 ]
Fix Version/s	10.0.7 [ 14100 ]

Sergei Golubchik made changes - 2014-01-24 20:51

Status

Open [ 1 ]

In Progress [ 3 ]

Sergei Golubchik made changes - 2014-01-28 01:18

Fix Version/s	5.3.13 [ 12602 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2014-06-13 15:06

Workflow

defaullt [ 30638 ]

MariaDB v2 [ 42831 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:50

Workflow

MariaDB v2 [ 42831 ]

MariaDB v3 [ 61849 ]

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

Workflow

MariaDB v3 [ 61849 ]

MariaDB v4 [ 147312 ]

People

Assignee:: Sergei Golubchik

Reporter:: Rich Prohaska

Votes:: 0 Vote for this issue

Watchers:: 5 Start watching this issue

Dates

Created:: 2013-12-06 22:08

Updated:: 2014-01-29 19:20

Resolved:: 2014-01-28 01:18

Git Integration

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

MariaDB Server

Details

Description

Attachments

Activity

People

Dates

Git Integration