[MDEV-20824] InnoDB: Failing assertion: (block)->index || my_atomic_loadlint(&(block)->n_pointers) == 0 in buf0buf.cc Created: 2019-10-14  Updated: 2023-04-16  Resolved: 2023-04-16

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3.19
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Matthias Leich Assignee: Marko Mäkelä
Resolution: Cannot Reproduce Votes: 0
Labels: None

Attachments: File MDEV-20824.cfg     File MDEV-20824.yy    

 Description   

Assert hit during RQG testing on
10.3 fa6c6062574f091638f1143ef67eee4fc111fb32 2019-10-12
compiled with debug.
Version: '10.3.19-MariaDB-debug-log'  socket: ...
2019-10-14 12:56:12 0x7fb9fc071700  InnoDB: Assertion failure in file storage/innobase/buf/buf0buf.cc line 3275
InnoDB: Failing assertion: (block)->index || my_atomic_loadlint(&(block)->n_pointers) == 0
...
191014 12:56:12 [ERROR] mysqld got signal 6 ;
 | Query (0x7fb948010890): ALTER TABLE t4 DROP COLUMN IF EXISTS col_int_g, LOCK = DEFAULT, ALGORITHM = NOCOPY  /* E_R Thread10 QNO 244 CON_ID 25 */
 | Connection ID (thread ID): 25
 | Status: NOT_KILLED
...
#3  <signal handler called>
 #4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
 #5  0x00007fba06b1837a in __GI_abort () at abort.c:89
 #6  0x00005621867a7f82 in ut_dbg_assertion_failed (expr=0x562186f2a830 "(block)->index || my_atomic_loadlint(&(block)->n_pointers) == 0", file=0x562186f2ae00 "storage/innobase/buf/buf0buf.cc", line=3275) at storage/innobase/ut/ut0dbg.cc:60
 #7  0x000056218682759a in buf_pool_clear_hash_index () at storage/innobase/buf/buf0buf.cc:3275
 #8  0x000056218680a299 in btr_search_disable (need_mutex=false) at storage/innobase/btr/btr0sea.cc:397
 #9  0x0000562186570496 in ha_innobase::commit_inplace_alter_table (this=0x7fb9480d1770, altered_table=0x7fb9480e42a8, ha_alter_info=0x7fb9fc06e220, commit=true) at storage/innobase/handler/handler0alter.cc:9714
 #10 0x00005621862fcfaf in handler::ha_commit_inplace_alter_table (this=0x7fb9480d1770, altered_table=0x7fb9480e42a8, ha_alter_info=0x7fb9fc06e220, commit=true) at sql/handler.cc:4576
 #11 0x00005621860bb814 in mysql_inplace_alter_table (thd=0x7fb948000a98, table_list=0x7fb948010a30, table=0x7fb9480e7148, altered_table=0x7fb9480e42a8, ha_alter_info=0x7fb9fc06e220, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7fb9fc06e390, alter_ctx=0x7fb9fc06e940) at sql/sql_table.cc:7643
 #12 0x00005621860c1d93 in mysql_alter_table (thd=0x7fb948000a98, new_db=0x7fb948005180, new_name=0x7fb948005540, create_info=0x7fb9fc06f530, table_list=0x7fb948010a30, alter_info=0x7fb9fc06f470, order_num=0, order=0x0, ignore=false) at sql/sql_table.cc:9854
 #13 0x000056218614fce3 in Sql_cmd_alter_table::execute (this=0x7fb9480110c0, thd=0x7fb948000a98) at sql/sql_alter.cc:500
 #14 0x0000562185fe23de in mysql_execute_command (thd=0x7fb948000a98) at sql/sql_parse.cc:6023
 #15 0x0000562185fe7b51 in mysql_parse (thd=0x7fb948000a98, rawbuf=0x7fb948010890 "ALTER TABLE t4 DROP COLUMN IF EXISTS col_int_g, LOCK = DEFAULT, ALGORITHM = NOCOPY  /* E_R Thread10 QNO 244 CON_ID 25 */", length=120, parser_state=0x7fb9fc070630, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:7829
 #16 0x0000562185fd478b in dispatch_command (command=COM_QUERY, thd=0x7fb948000a98, packet=0x7fb948008559 " ALTER TABLE t4 DROP COLUMN IF EXISTS col_int_g, LOCK = DEFAULT, ALGORITHM = NOCOPY  /* E_R Thread10 QNO 244 CON_ID 25 */ ", packet_length=122, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:1855
 #17 0x0000562185fd30d3 in do_command (thd=0x7fb948000a98) at sql/sql_parse.cc:1400
 #18 0x0000562186149de4 in do_handle_one_connection (connect=0x56218bd34c68) at sql/sql_connect.cc:1403
 #19 0x0000562186149b46 in handle_one_connection (arg=0x56218bd34c68) at sql/sql_connect.cc:1308
 #20 0x00007fba077576da in start_thread (arg=0x7fb9fc071700) at pthread_create.c:456



 Comments   
Comment by Marko Mäkelä [ 2023-04-14 ]

Is this still reproducible in more recent versions? There have been multiple fixes to the adaptive hash index in the past few years.

Comment by Matthias Leich [ 2023-04-14 ]

The corresponding error patterns
- InnoDB: Assertion failure in file storage/innobase/buf/buf0buf.cc line 3275
  InnoDB: Failing assertion: (block)->index || my_atomic_loadlint(&(block)->n_pointers) == 0
  was hit last time before 2020-12-02
  AFAIR the replay test above revealed this bug only.
- InnoDB: Assertion failure in file /home/mleich/Server/bb-10.3-MDEV-23072/storage/innobase/btr/btr0sea.cc line 668
  InnoDB: Failing assertion: (block)->index || my_atomic_loadlint(&(block)->n_pointers) == 0
  was hit last time 2022-10-17 on some origin/bb-10.3-midenok-MDEV-25004 5fc0530dd8ff8f9d8b9e486f781f4b438dbe9c51 2022-10-11T23:17:03+03:00
  But here the assert is in btr0sea.cc  and not in buf0buf.cc like described on top.
 
I tried the replay test on
- bb-10.4-thiru a8b25f0990558eb7dd316151bda4e1d730cd02be 2023-04-11T18:52:16+05:30
  No replay of any failure within ~ 900 RQG tests.
- origin/10.3 4c4939bbf619d7e516131c0b3e5691b1c2d2ff8f 2023-03-09T15:32:32+01:00
  which claims to be a 10.3.39.
  No replay of any failure within ~ 1100 RQG tests.

Comment by Matthias Leich [ 2023-04-14 ]

I vote for closing the bug as "no more repeatable".
But I do not know when 10.3 reached a state were the bug was no more repeatable.

Comment by Marko Mäkelä [ 2023-04-16 ]

mleich, the main thing is that this bug was been fixed at some point. I remember that we spent effort fixing bugs related to the adaptive hash index some 2 years ago, and I suppose that your broadband testing is still exercising that subsystem.

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