Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-24560

SIGSEGV in st_join_table::cleanup + server and client hang + cross-mysqld-interaction + double free or corruption (!prev)

Details

    Description

      Similar to MDEV-24262, but different testcase

      CREATE TABLE t(a VARCHAR(16383) CHARACTER SET UTF32, KEY k(a)) ENGINE=InnoDB;
      		 
      SET SESSION sql_buffer_result=ON;
      		 
      SET SESSION big_tables=ON;
      		 
      SELECT DISTINCT COUNT(DISTINCT a) FROM t;

      Leads to:

      10.6.0 9118fd360a3da0bba521caf2a35c424968235ac4 (Debug)

      		 
      Core was generated by `/test/MD010121-mariadb-10.6.0-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
      		 
      Program terminated with signal SIGSEGV, Segmentation fault.
      		 
      #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
      		 
          at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
      		 
      [Current thread is 1 (Thread 0x1524b0e9f700 (LWP 2400942))]
      		 
      (gdb) bt
      		 
      #0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
      		 
      #1  0x0000561bf4e500d7 in my_write_core (sig=sig@entry=11) at /test/10.6_dbg/mysys/stacktrace.c:424
      		 
      #2  0x0000561bf45e4ab1 in handle_fatal_signal (sig=11) at /test/10.6_dbg/sql/signal_handler.cc:330
      		 
      #3  <signal handler called>
      		 
      #4  0x0000561bf43777a9 in st_join_table::cleanup (this=this@entry=0x1524780155b8) at /test/10.6_dbg/sql/sql_select.cc:13444
      		 
      #5  0x0000561bf4395951 in JOIN::cleanup (this=this@entry=0x152478013f70, full=full@entry=true) at /test/10.6_dbg/sql/sql_select.cc:13882
      		 
      #6  0x0000561bf4395dfb in JOIN::destroy (this=0x152478013f70) at /test/10.6_dbg/sql/sql_select.cc:4501
      		 
      #7  0x0000561bf440fd3b in st_select_lex::cleanup (this=this@entry=0x152478012778) at /test/10.6_dbg/sql/sql_union.cc:2746
      		 
      #8  0x0000561bf43a0b40 in mysql_select (thd=thd@entry=0x152478000db8, tables=0x152478012ef8, fields=@0x1524780128c8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x152478012e98, last = 0x152478012e98, elements = 1}, <No data fields>}, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147879681, result=0x152478013f48, unit=0x152478004f80, select_lex=0x152478012778) at /test/10.6_dbg/sql/sql_select.cc:4687
      		 
      #9  0x0000561bf43a0cd0 in handle_select (thd=thd@entry=0x152478000db8, lex=lex@entry=0x152478004eb8, result=result@entry=0x152478013f48, setup_tables_done_option=setup_tables_done_option@entry=0) at /test/10.6_dbg/sql/sql_select.cc:417
      		 
      #10 0x0000561bf431319d in execute_sqlcom_select (thd=thd@entry=0x152478000db8, all_tables=0x152478012ef8) at /test/10.6_dbg/sql/sql_parse.cc:6116
      		 
      #11 0x0000561bf431fc7c in mysql_execute_command (thd=thd@entry=0x152478000db8) at /test/10.6_dbg/sql/sql_parse.cc:3820
      		 
      #12 0x0000561bf430c072 in mysql_parse (thd=thd@entry=0x152478000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1524b0e9e3d0) at /test/10.6_dbg/sql/sql_parse.cc:7881
      		 
      #13 0x0000561bf431a1ec in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x152478000db8, packet=packet@entry=0x152478008d39 "SELECT DISTINCT COUNT(DISTINCT a) FROM t", packet_length=packet_length@entry=40) at /test/10.6_dbg/sql/sql_class.h:1293
      		 
      #14 0x0000561bf431d52d in do_command (thd=0x152478000db8) at /test/10.6_dbg/sql/sql_parse.cc:1348
      		 
      #15 0x0000561bf44797fc in do_handle_one_connection (connect=<optimized out>, connect@entry=0x561bf7a2e6f8, put_in_cache=put_in_cache@entry=true) at /test/10.6_dbg/sql/sql_connect.cc:1410
      		 
      #16 0x0000561bf4479f03 in handle_one_connection (arg=arg@entry=0x561bf7a2e6f8) at /test/10.6_dbg/sql/sql_connect.cc:1312
      		 
      #17 0x0000561bf492f88f in pfs_spawn_thread (arg=0x561bf797a898) at /test/10.6_dbg/storage/perfschema/pfs.cc:2201
      		 
      #18 0x00001524c622d609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      		 
      #19 0x00001524c5e1c293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

      10.6.0 9118fd360a3da0bba521caf2a35c424968235ac4 (Optimized)

      		 
      2021-01-11 15:33:44 0 [Note] /test/MD010121-mariadb-10.6.0-linux-x86_64-opt/bin/mysqld: ready for connections.
      		 
      Version: '10.6.0-MariaDB'  socket: '/test/MD010121-mariadb-10.6.0-linux-x86_64-opt/socket.sock'  port: 18336  MariaDB Server
      		 
      double free or corruption (!prev)
      		 
      210111 15:33:53 [ERROR] mysqld got signal 6 ;
      		 
      This could be because you hit a bug. It is also possible that this binary
      		 
      or one of the libraries it was linked against is corrupt, improperly built,
      		 
      or misconfigured. This error can also be caused by malfunctioning hardware.
      		 
       
      		 
      To report this bug, see https://mariadb.com/kb/en/reporting-bugs
      		 
       
      		 
      We will try our best to scrape up some info that will hopefully help
      		 
      diagnose the problem, but since we have already crashed,
      		 
      something is definitely wrong and this may fail.
      		 
       
      		 
      Server version: 10.6.0-MariaDB
      		 
      key_buffer_size=134217728
      		 
      read_buffer_size=131072
      		 
      max_used_connections=1
      		 
      max_threads=153
      		 
      thread_count=2
      		 
      It is possible that mysqld could use up to
      		 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467868 K  bytes of memory
      		 
      Hope that's ok; if not, decrease some variables in the equation.
      		 
       
      		 
      Thread pointer: 0x14799c000c58
      		 
      Attempting backtrace. You can use the following information to find out
      		 
      where mysqld died. If you see no messages after this, something went
      		 
      terribly wrong...
      		 
      stack_bottom = 0x147a08f2bd58 thread_stack 0x49000

      Bug confirmed present in:
      MariaDB: 10.2.37 (dbg), 10.2.37 (opt), 10.3.28 (dbg), 10.3.28 (opt), 10.4.18 (dbg), 10.4.18 (opt), 10.5.9 (dbg), 10.5.9 (opt), 10.6.0 (dbg), 10.6.0 (opt)

      Bug (or feature/syntax) confirmed not present in:
      MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.50 (dbg), 5.6.50 (opt), 5.7.32 (dbg), 5.7.32 (opt), 8.0.22 (dbg), 8.0.22 (opt)

      Optimized builds 10.2-10.6 will hang for both server and client (i.e. client will hang whilst trying to connect) even though the server is already crashed (with double free or corruption) as per the error log:

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24262 Server crashes in st_join_table::cleanup upon erroneous GROUP_CONCAT

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-28077 "Wrong create options" with "big_tables" option enabled

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-28354 SIGSEGV's in free_root and st_join_table::cleanup

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 10 older comments
            oleg.smirnov Oleg Smirnov added a comment - - edited

            Pushed to preview-10.2-MDEV-24560MDEV-24262MDEV-28077. When merging this branch into later versions of MariaDB Server some tests will start to fail: select.test, select_jcl6.test, select_pkeycache.test will start to produce such warnings on SET SESSION big_tables=ON:
            Warnings:
            Warning 1287 '@@big_tables' is deprecated and will be removed in a future release

            oleg.smirnov Oleg Smirnov added a comment - - edited Pushed to preview-10.2- MDEV-24560 MDEV-24262 MDEV-28077 . When merging this branch into later versions of MariaDB Server some tests will start to fail: select.test, select_jcl6.test, select_pkeycache.test will start to produce such warnings on SET SESSION big_tables=ON : Warnings: Warning 1287 '@@big_tables' is deprecated and will be removed in a future release
            oleg.smirnov Oleg Smirnov added a comment -

            Pushed to 10.2:

            commit 53b580a91c12e9272623fc45496631be65313dd8
            Author: Oleg Smirnov <olernov@gmail.com>
            Date: Thu Mar 24 14:57:23 2022 +0700

            MDEV-28077 'Wrong create options' error with 'big_tables' enabled

            The cause of the bug is overflow of uint16 KEY_PART_INFO::length and/or
            uint16 KEY_PART_INFO::store_length. The solution is to increase the size
            of those variables to the 'uint' type (which is 32-bit long)

            commit 85192553ae2c3cb5fb26ace4cd85377525ac7845
            Author: Oleg Smirnov <olernov@gmail.com>
            Date: Fri Mar 11 21:18:34 2022 +0700

            MDEV-24560 SIGSEGV in st_join_table::cleanup

            If JOIN::create_postjoin_aggr_table encounters errors during execution
            then free_tmp_table() is then called twice for JOIN_TAB::aggr.
            The solution is to initialize JOIN_TAB::aggr only on successful completion
            of JOIN::create_postjoin_aggr_table

            oleg.smirnov Oleg Smirnov added a comment - Pushed to 10.2 : commit 53b580a91c12e9272623fc45496631be65313dd8 Author: Oleg Smirnov <olernov@gmail.com> Date: Thu Mar 24 14:57:23 2022 +0700 MDEV-28077 'Wrong create options' error with 'big_tables' enabled The cause of the bug is overflow of uint16 KEY_PART_INFO::length and/or uint16 KEY_PART_INFO::store_length. The solution is to increase the size of those variables to the 'uint' type (which is 32-bit long) commit 85192553ae2c3cb5fb26ace4cd85377525ac7845 Author: Oleg Smirnov <olernov@gmail.com> Date: Fri Mar 11 21:18:34 2022 +0700 MDEV-24560 SIGSEGV in st_join_table::cleanup If JOIN::create_postjoin_aggr_table encounters errors during execution then free_tmp_table() is then called twice for JOIN_TAB::aggr. The solution is to initialize JOIN_TAB::aggr only on successful completion of JOIN::create_postjoin_aggr_table
            Roel Roel Van de Paar added a comment - - edited

            oleg.smirnov In one of the test runs which was still reducing, I found the following testcase (CLI):

            SET big_tables=ON;
            		 
            CREATE TABLE t (a VARCHAR(16383) CHARACTER SET UTF32,KEY k1 (a (768))) ENGINE=InnoDB;
            		 
            SET SESSION sql_buffer_result=1;
            		 
            DELETE FROM mysql.user WHERE USER=0;
            		 
            EXPLAIN SELECT COUNT(DISTINCT a) FROM t;

            Which produces the following uniqueID's:

            SIGSEGV|_int_free|free_root|free_tmp_table|JOIN::cleanup
            		 
            SIGSEGV|_int_free|root_free|free_root|free_tmp_table
            		 
            SIGSEGV|st_join_table::cleanup|JOIN::cleanup|JOIN::destroy|st_select_lex::cleanup

            With the first two of those being new ones.
            Here are two example traces for those uniqueID's:

            10.5.16 73fee39ea62037780c59161507e89dd76c10b7a3 (Optimized)

            		 
            Core was generated by `/test/MD160322-mariadb-10.5.16-linux-x86_64-opt/bin/mysqld --no-defaults --core'.
            		 
            Program terminated with signal SIGSEGV, Segmentation fault.
            		 
            #0  _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, 
                have_lock=<optimized out>) at malloc.c:4316
            		 
            [Current thread is 1 (Thread 0x14aa543fa700 (LWP 2286515))]
            		 
            (gdb) bt
            		 
            #0  _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, have_lock=<optimized out>) at malloc.c:4316
            		 
            #1  0x000056297d628b45 in free_root (root=root@entry=0x14aa543f8d60, MyFlags=MyFlags@entry=0) at /test/10.5_opt/mysys/my_alloc.c:410
            		 
            #2  0x000056297ce84b60 in free_tmp_table (thd=0x14a9cc000c58, entry=0x14a9cc0435e0) at /test/10.5_opt/sql/sql_select.cc:20211
            		 
            #3  0x000056297ce9ea1f in JOIN::cleanup (this=this@entry=0x14a9cc012410, full=full@entry=true) at /test/10.5_opt/sql/sql_select.cc:14065
            		 
            #4  0x000056297ce9ed3a in JOIN::destroy (this=0x14a9cc012410) at /test/10.5_opt/sql/sql_select.cc:4567
            		 
            #5  0x000056297cef7abd in st_select_lex::cleanup (this=this@entry=0x14a9cc0104a8) at /test/10.5_opt/sql/sql_union.cc:2790
            		 
            #6  0x000056297cef7cf0 in st_select_lex_unit::cleanup (this=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2596
            		 
            #7  st_select_lex_unit::cleanup (this=this@entry=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2557
            		 
            #8  0x000056297ce3e57c in mysql_execute_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:6085
            		 
            #9  0x000056297ce2ddb3 in mysql_parse (thd=0x14a9cc000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_parse.cc:8100
            		 
            #10 0x000056297ce3abcd in dispatch_command (command=COM_QUERY, thd=0x14a9cc000c58, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_class.h:1290
            		 
            #11 0x000056297ce3d3a2 in do_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:1370
            		 
            #12 0x000056297cf44f31 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x562980469788, put_in_cache=put_in_cache@entry=true) at /test/10.5_opt/sql/sql_connect.cc:1418
            		 
            #13 0x000056297cf453ad in handle_one_connection (arg=arg@entry=0x562980469788) at /test/10.5_opt/sql/sql_connect.cc:1312
            		 
            #14 0x000056297d2da4f2 in pfs_spawn_thread (arg=0x5629803ea438) at /test/10.5_opt/storage/perfschema/pfs.cc:2201
            		 
            #15 0x000014aa574ac609 in start_thread (arg=<optimized out>) at pthread_create.c:477
            		 
            #16 0x000014aa57098163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

            10.9.0 5be92887c2caacb45af87b1131db952ce627e83a (Optimized)

            		 
            Core was generated by `/test/MD160322-mariadb-10.9.0-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
            		 
            Program terminated with signal SIGSEGV, Segmentation fault.
            		 
            #0  _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, 
                have_lock=<optimized out>) at malloc.c:4316
            		 
            [Current thread is 1 (Thread 0x1504f41a6700 (LWP 2454660))]
            		 
            (gdb) bt
            		 
            #0  _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, have_lock=<optimized out>) at malloc.c:4316
            		 
            #1  0x000055f19aad94f5 in root_free (root=0x1504f41a4de0, size=<optimized out>, ptr=<optimized out>) at /test/10.9_opt/mysys/my_alloc.c:78
            		 
            #2  free_root (root=root@entry=0x1504f41a4de0, MyFlags=MyFlags@entry=0) at /test/10.9_opt/mysys/my_alloc.c:495
            		 
            #3  0x000055f19a39f589 in free_tmp_table (thd=0x150460000c58, entry=0x15046003f560) at /test/10.9_opt/sql/sql_select.cc:20406
            		 
            #4  0x000055f19a3b8cdf in JOIN::cleanup (this=this@entry=0x150460012708, full=full@entry=true) at /test/10.9_opt/sql/sql_select.cc:14280
            		 
            #5  0x000055f19a3b904a in JOIN::destroy (this=0x150460012708) at /test/10.9_opt/sql/sql_select.cc:4778
            		 
            #6  0x000055f19a41401d in st_select_lex::cleanup (this=this@entry=0x150460010968) at /test/10.9_opt/sql/sql_union.cc:2788
            		 
            #7  0x000055f19a414258 in st_select_lex_unit::cleanup (this=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2594
            		 
            #8  st_select_lex_unit::cleanup (this=this@entry=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2555
            		 
            #9  0x000055f19a34b564 in mysql_execute_command (thd=0x150460000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:6017
            		 
            #10 0x000055f19a33c1c6 in mysql_parse (thd=0x150460000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:8027
            		 
            #11 0x000055f19a348375 in dispatch_command (command=COM_QUERY, thd=0x150460000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.9_opt/sql/sql_class.h:1362
            		 
            #12 0x000055f19a34a567 in do_command (thd=0x150460000c58, blocking=blocking@entry=true) at /test/10.9_opt/sql/sql_parse.cc:1402
            		 
            #13 0x000055f19a469e97 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/10.9_opt/sql/sql_connect.cc:1418
            		 
            #14 0x000055f19a46a1dd in handle_one_connection (arg=arg@entry=0x55f19c89fc38) at /test/10.9_opt/sql/sql_connect.cc:1312
            		 
            #15 0x000055f19a7e38d1 in pfs_spawn_thread (arg=0x55f19c8579c8) at /test/10.9_opt/storage/perfschema/pfs.cc:2201
            		 
            #16 0x000015051596f609 in start_thread (arg=<optimized out>) at pthread_create.c:477
            		 
            #17 0x000015051555b163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

            Additionally, 10.2.44 (opt) hangs when running the testcase, and any CLI connect will hang also. The issue is readily reproducible. GDB break-in coredump can be provided if needed, but I assume it's easy to reproduce on your site for the same (if the patch does not fix it)

            Assuming you have a build ready, could you please check that this testcase is also resolved with your patch? If not, I can create a new bug.

            Roel Roel Van de Paar added a comment - - edited oleg.smirnov In one of the test runs which was still reducing, I found the following testcase (CLI): SET big_tables= ON ; CREATE TABLE t (a VARCHAR (16383) CHARACTER SET UTF32, KEY k1 (a (768))) ENGINE=InnoDB; SET SESSION sql_buffer_result=1; DELETE FROM mysql. user WHERE USER =0; EXPLAIN SELECT COUNT ( DISTINCT a) FROM t; Which produces the following uniqueID's: SIGSEGV|_int_free|free_root|free_tmp_table|JOIN::cleanup SIGSEGV|_int_free|root_free|free_root|free_tmp_table SIGSEGV|st_join_table::cleanup|JOIN::cleanup|JOIN::destroy|st_select_lex::cleanup With the first two of those being new ones. Here are two example traces for those uniqueID's: 10.5.16 73fee39ea62037780c59161507e89dd76c10b7a3 (Optimized) Core was generated by `/test/MD160322-mariadb-10.5.16-linux-x86_64-opt/bin/mysqld --no-defaults --core'. Program terminated with signal SIGSEGV, Segmentation fault. #0 _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, have_lock=<optimized out>) at malloc.c:4316 [Current thread is 1 (Thread 0x14aa543fa700 (LWP 2286515))] (gdb) bt #0 _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, have_lock=<optimized out>) at malloc.c:4316 #1 0x000056297d628b45 in free_root (root=root@entry=0x14aa543f8d60, MyFlags=MyFlags@entry=0) at /test/10.5_opt/mysys/my_alloc.c:410 #2 0x000056297ce84b60 in free_tmp_table (thd=0x14a9cc000c58, entry=0x14a9cc0435e0) at /test/10.5_opt/sql/sql_select.cc:20211 #3 0x000056297ce9ea1f in JOIN::cleanup (this=this@entry=0x14a9cc012410, full=full@entry=true) at /test/10.5_opt/sql/sql_select.cc:14065 #4 0x000056297ce9ed3a in JOIN::destroy (this=0x14a9cc012410) at /test/10.5_opt/sql/sql_select.cc:4567 #5 0x000056297cef7abd in st_select_lex::cleanup (this=this@entry=0x14a9cc0104a8) at /test/10.5_opt/sql/sql_union.cc:2790 #6 0x000056297cef7cf0 in st_select_lex_unit::cleanup (this=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2596 #7 st_select_lex_unit::cleanup (this=this@entry=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2557 #8 0x000056297ce3e57c in mysql_execute_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:6085 #9 0x000056297ce2ddb3 in mysql_parse (thd=0x14a9cc000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_parse.cc:8100 #10 0x000056297ce3abcd in dispatch_command (command=COM_QUERY, thd=0x14a9cc000c58, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_class.h:1290 #11 0x000056297ce3d3a2 in do_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:1370 #12 0x000056297cf44f31 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x562980469788, put_in_cache=put_in_cache@entry=true) at /test/10.5_opt/sql/sql_connect.cc:1418 #13 0x000056297cf453ad in handle_one_connection (arg=arg@entry=0x562980469788) at /test/10.5_opt/sql/sql_connect.cc:1312 #14 0x000056297d2da4f2 in pfs_spawn_thread (arg=0x5629803ea438) at /test/10.5_opt/storage/perfschema/pfs.cc:2201 #15 0x000014aa574ac609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #16 0x000014aa57098163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 10.9.0 5be92887c2caacb45af87b1131db952ce627e83a (Optimized) Core was generated by `/test/MD160322-mariadb-10.9.0-linux-x86_64-opt/bin/mysqld --no-defaults --core-'. Program terminated with signal SIGSEGV, Segmentation fault. #0 _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, have_lock=<optimized out>) at malloc.c:4316 [Current thread is 1 (Thread 0x1504f41a6700 (LWP 2454660))] (gdb) bt #0 _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, have_lock=<optimized out>) at malloc.c:4316 #1 0x000055f19aad94f5 in root_free (root=0x1504f41a4de0, size=<optimized out>, ptr=<optimized out>) at /test/10.9_opt/mysys/my_alloc.c:78 #2 free_root (root=root@entry=0x1504f41a4de0, MyFlags=MyFlags@entry=0) at /test/10.9_opt/mysys/my_alloc.c:495 #3 0x000055f19a39f589 in free_tmp_table (thd=0x150460000c58, entry=0x15046003f560) at /test/10.9_opt/sql/sql_select.cc:20406 #4 0x000055f19a3b8cdf in JOIN::cleanup (this=this@entry=0x150460012708, full=full@entry=true) at /test/10.9_opt/sql/sql_select.cc:14280 #5 0x000055f19a3b904a in JOIN::destroy (this=0x150460012708) at /test/10.9_opt/sql/sql_select.cc:4778 #6 0x000055f19a41401d in st_select_lex::cleanup (this=this@entry=0x150460010968) at /test/10.9_opt/sql/sql_union.cc:2788 #7 0x000055f19a414258 in st_select_lex_unit::cleanup (this=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2594 #8 st_select_lex_unit::cleanup (this=this@entry=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2555 #9 0x000055f19a34b564 in mysql_execute_command (thd=0x150460000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:6017 #10 0x000055f19a33c1c6 in mysql_parse (thd=0x150460000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:8027 #11 0x000055f19a348375 in dispatch_command (command=COM_QUERY, thd=0x150460000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.9_opt/sql/sql_class.h:1362 #12 0x000055f19a34a567 in do_command (thd=0x150460000c58, blocking=blocking@entry=true) at /test/10.9_opt/sql/sql_parse.cc:1402 #13 0x000055f19a469e97 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/10.9_opt/sql/sql_connect.cc:1418 #14 0x000055f19a46a1dd in handle_one_connection (arg=arg@entry=0x55f19c89fc38) at /test/10.9_opt/sql/sql_connect.cc:1312 #15 0x000055f19a7e38d1 in pfs_spawn_thread (arg=0x55f19c8579c8) at /test/10.9_opt/storage/perfschema/pfs.cc:2201 #16 0x000015051596f609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #17 0x000015051555b163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Additionally, 10.2.44 (opt) hangs when running the testcase, and any CLI connect will hang also. The issue is readily reproducible. GDB break-in coredump can be provided if needed, but I assume it's easy to reproduce on your site for the same (if the patch does not fix it) Assuming you have a build ready, could you please check that this testcase is also resolved with your patch? If not, I can create a new bug.
            oleg.smirnov Oleg Smirnov added a comment -

            Confirmed: trunk 10.2 (which includes the patch) crashes on your test case. Please file a new bug.

            oleg.smirnov Oleg Smirnov added a comment - Confirmed: trunk 10.2 (which includes the patch) crashes on your test case. Please file a new bug.
            Roel Roel Van de Paar added a comment -

            Thank you. Filed MDEV-28354 SIGSEGV's in free_root and st_join_table::cleanup

            Roel Roel Van de Paar added a comment - Thank you. Filed MDEV-28354 SIGSEGV's in free_root and st_join_table::cleanup

            People

              oleg.smirnov Oleg Smirnov
              Roel Roel Van de Paar
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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