Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4(EOL)
-
None
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 ()
|
Attachments
Issue Links
- includes
-
-
- Closed
-
Activity
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:
- remove key_map from KEY (unlikely)
- replace memcpy/memmove and bzero with proper assignments and initialization (I have an incomplete patch
doing that) - 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.
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.
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.
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
Two side notes: