[MDEV-19235] MariaDB Server compiled for 128 Indexes crashes at startup Created: 2019-04-10  Updated: 2023-05-16  Resolved: 2019-05-09

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.4
Fix Version/s: 10.4.5

Type: Bug Priority: Critical
Reporter: Axel Schwenke Assignee: Vladislav Vaintroub
Resolution: Fixed Votes: 0
Labels: None

Attachments: File max-indexes-128.diff    
Issue Links:
Blocks
PartOf
includes MDEV-19266 Crash in EITS code when enabling 128 ... Closed

 Description   

I compiled MariaDB-10.4.4 from the released tarball with support for 128 indexes by using -DMAX_INDEXES=128 for cmake. The binary crashes when mysql_install_db creates system tables. In order to get a proper stack trace I started the binary on an existing datadir. It also crashes at startup; this time producing a proper stack trace:

#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
#1  0x0000561495f95767 in my_write_core (sig=sig@entry=11) at /home/axel/mariadb-source/mariadb-10.4.4/mysys/stacktrace.c:481
 
#2  0x0000561495a1680b in handle_fatal_signal (sig=11) at /home/axel/mariadb-source/mariadb-10.4.4/sql/signal_handler.cc:305
 
#3  <signal handler called>
 
#4  Bitmap<128u>::set_bit (this=<optimized out>, n=0) at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_bitmap.h:46
 
#5  TABLE_SHARE::set_overlapped_keys (this=this@entry=0x5614c15e0fd0) at /home/axel/mariadb-source/mariadb-10.4.4/sql/table.cc:1317
 
#6  0x00005614958c91e4 in TABLE_SHARE::init_from_binary_frm_image (this=this@entry=0x5614c15e0fd0, thd=thd@entry=0x5614c15c6808, 
    write=write@entry=false, frm_image=frm_image@entry=0x5614c15e14d8 "\376\001\n*\022", frm_length=frm_length@entry=1516)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/table.cc:2817
 
#7  0x00005614958ca65b in open_table_def (thd=thd@entry=0x5614c15c6808, share=share@entry=0x5614c15e0fd0, flags=flags@entry=11)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/table.cc:696
 
#8  0x0000561495999ad1 in tdc_acquire_share (thd=thd@entry=0x5614c15c6808, tl=tl@entry=0x7ffda1ce6690, flags=flags@entry=3, 
    out_table=out_table@entry=0x7ffda1ce5c18) at /home/axel/mariadb-source/mariadb-10.4.4/sql/table_cache.cc:840
 
#9  0x00005614957a5a87 in open_table (thd=thd@entry=0x5614c15c6808, table_list=table_list@entry=0x7ffda1ce6690, 
    ot_ctx=ot_ctx@entry=0x7ffda1ce6280) at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_base.cc:1897
 
#10 0x00005614957a93a3 in open_and_process_table (ot_ctx=0x7ffda1ce6280, has_prelocking_list=false, prelocking_strategy=0x7ffda1ce6580, 
    flags=2048, counter=0x7ffda1ce64dc, tables=0x7ffda1ce6690, lex=0x5614c15ca4b0, thd=0x5614c15c6808)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_base.cc:3732
 
#11 open_tables (thd=thd@entry=0x5614c15c6808, options=..., start=start@entry=0x7ffda1ce64c8, counter=counter@entry=0x7ffda1ce64dc, 
    flags=flags@entry=2048, prelocking_strategy=prelocking_strategy@entry=0x7ffda1ce6580)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_base.cc:4263
 
#12 0x00005614957a9fd3 in open_and_lock_tables (thd=thd@entry=0x5614c15c6808, options=..., tables=<optimized out>, 
    tables@entry=0x7ffda1ce6690, derived=derived@entry=false, flags=flags@entry=2048, 
    prelocking_strategy=prelocking_strategy@entry=0x7ffda1ce6580) at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_base.cc:5147
 
#13 0x0000561495816406 in open_and_lock_tables (flags=2048, derived=false, tables=0x7ffda1ce6690, thd=<optimized out>)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_base.h:502
 
#14 plugin_load (tmp_root=tmp_root@entry=0x7ffda1ce7000) at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_plugin.cc:1815
 
#15 0x000056149581ce19 in plugin_init (argc=argc@entry=0x561496951128 <remaining_argc>, argv=0x56149804b5b8, flags=0)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/sql_plugin.cc:1734
 
#16 0x00005614957493c1 in init_server_components () at /home/axel/mariadb-source/mariadb-10.4.4/sql/mysqld.cc:5174
 
#17 0x000056149574b792 in mysqld_main (argc=<optimized out>, argv=<optimized out>)
 
    at /home/axel/mariadb-source/mariadb-10.4.4/sql/mysqld.cc:5703
 
#18 0x00007fbdf0614b97 in __libc_start_main (main=0x5614957272e0 <main(int, char**)>, argc=8, argv=0x7ffda1ce78a8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffda1ce7898) at ../csu/libc-start.c:310
 
#19 0x000056149573f46a in _start ()



 Comments   
Comment by Axel Schwenke [ 2019-04-10 ]

Two side notes:

  1. cmake does not expose the MAX_INDEXES configuration variable, so it is not possible to use ccmake to see the current setting and change it. This should be fixed.
  2. cmake imposes an (artificial?) limit of 128 indexes.
Comment by Sergei Golubchik [ 2019-04-11 ]

The crash is caused by

  key_map overlapped;
 
  key_map constraint_correlated;

members of the KEY class that were added in 10.4.
With MAX_INDEXES=128, key_map is not a "trivial" type anymore. With key_map in KEY it makes KEY non-trivial. And KEY objects are widely memcpy-ed and bzero-ed.

I see three possible ways to fix it:

  1. remove key_map from KEY (unlikely)
  2. replace memcpy/memmove and bzero with proper assignments and initialization (I have an incomplete patch doing that)
  3. rewrite Bitmap<> to be a "tirvial" class, not use MY_BITMAP there. Basically, inlining MY_BITMAP in Bitmap<>, removing pointers, hard-coding last_word_mask and n_bits. It should make the Bitmap<> faster, as a bonus.
Comment by Axel Schwenke [ 2019-04-11 ]

rewrite Bitmap<> to be a "tirvial" class, not use MY_BITMAP there. It should make the Bitmap<> faster, as a bonus.

If I had a vote, I would put it here. C++ certainly has a suitable container that could be used instead of MY_BITMAP. std::bitset comes to mind. Or std::vector<bool>. Those will be portable and (hopefully) properly optimized. We will still need to use proper assignments to copy those struct members.

Comment by Sergei Golubchik [ 2019-04-15 ]

Yes, after discussing this bug with shagalla, we've agreed to try the last approach. Not necessarily an std container, though. Just something that can be as trivially coped and bzero'ed as ulonglong.

Comment by Vladislav Vaintroub [ 2019-04-18 ]

serg , could you please review https://github.com/MariaDB/server/commit/a4be420c920ef5faaf5b1735c22dd7958d0c26e7 ?

buildbot of this branch(which uses MAX_INDEXES=128)
http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.4-wlad-MDEV-19235

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