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

Server fails to produce a crash report with a stack trace in the error log

    XMLWordPrintable

Details

    Description

      This bug is not about the crash itself, this crash is reported as MDEV-19194. The test case is almost the same, with an addition of a prepared statement running SLEEP at the time of the crash. The difference it makes is that with this addition, the server reliably (at least for me, as of the moment, on all 10.x versions) fails to produce any stack trace in the error log. Without the PS with sleep it produces the stack trace from MDEV-19194 as expected.

      It is a real problem, as we often receive similar meaningless error logs from customers and users. It needs to be solved, if at all possible.

      --source include/have_innodb.inc
       
      CREATE TABLE tx (pk INT PRIMARY KEY) ENGINE=InnoDB;
      CREATE TABLE t1 (a INT, CONSTRAINT fk FOREIGN KEY (a) REFERENCES tx(pk)) ENGINE=InnoDB;
       
      --connect (con1,localhost,root,,)
      PREPARE stmt FROM ' SELECT SLEEP(0.001)';
      --send
          EXECUTE stmt;
       
      --connection default
      ALTER IGNORE TABLE t1 DROP FOREIGN KEY fk, DROP FOREIGN KEY fk, ALGORITHM=COPY;
       
      # Cleanup
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t1, tx;
      

      10.4 debug 18af13b8

      Version: '10.4.8-MariaDB-debug-log'  socket: '/data/bld/10.4-debug-nightly/mysql-test/var/tmp/mysqld.1.sock'  port: 16000  Source distribution
      190904 15:08:20 [ERROR] mysqld got signal 11 ;
      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.4.8-MariaDB-debug-log
      key_buffer_size=1048576
      read_buffer_size=131072
      max_used_connections=2
      max_threads=153
      thread_count=8
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 63616 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x7f54d4000b00
      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 = 0x7f551a257e70 thread_stack 0x49000
      

      If we look at all threads in the coredump, the thread 1 is the PS thread, not the crashing ALTER:

      Thread 1 (Thread 0x7f551a20d700 (LWP 27039)):
      #0  0x0000559d7a47fa95 in Protocol::send_result_set_row (this=0x7f54c80010c8, row_items=0x7f54c801afd8) at /data/src/10.4/sql/protocol.cc:1035
      #1  0x0000559d7a536138 in select_send::send_data (this=0x7f54c801bd10, items=...) at /data/src/10.4/sql/sql_class.cc:3003
      #2  0x0000559d7a5fe727 in JOIN::exec_inner (this=0x7f54c8011ee8) at /data/src/10.4/sql/sql_select.cc:4259
      #3  0x0000559d7a5fdfc4 in JOIN::exec (this=0x7f54c8011ee8) at /data/src/10.4/sql/sql_select.cc:4173
      #4  0x0000559d7a5ff6e7 in mysql_select (thd=0x7f54c8000b00, tables=0x0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416184064, result=0x7f54c801bd10, unit=0x7f54c80193a8, select_lex=0x7f54c801ae90) at /data/src/10.4/sql/sql_select.cc:4605
      #5  0x0000559d7a5ef4c7 in handle_select (thd=0x7f54c8000b00, lex=0x7f54c80192e0, result=0x7f54c801bd10, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:425
      #6  0x0000559d7a5b57a2 in execute_sqlcom_select (thd=0x7f54c8000b00, all_tables=0x0) at /data/src/10.4/sql/sql_parse.cc:6357
      #7  0x0000559d7a5aad4c in mysql_execute_command (thd=0x7f54c8000b00) at /data/src/10.4/sql/sql_parse.cc:3899
      #8  0x0000559d7a5d99a2 in Prepared_statement::execute (this=0x7f54c8018e80, expanded_query=0x7f551a20b560, open_cursor=false) at /data/src/10.4/sql/sql_prepare.cc:4760
      #9  0x0000559d7a5d7da7 in Prepared_statement::execute_loop (this=0x7f54c8018e80, expanded_query=0x7f551a20b560, open_cursor=false, packet=0x0, packet_end=0x0) at /data/src/10.4/sql/sql_prepare.cc:4246
      #10 0x0000559d7a5d57e5 in mysql_sql_stmt_execute (thd=0x7f54c8000b00) at /data/src/10.4/sql/sql_prepare.cc:3363
      #11 0x0000559d7a5aad91 in mysql_execute_command (thd=0x7f54c8000b00) at /data/src/10.4/sql/sql_parse.cc:3915
      #12 0x0000559d7a5b98ec in mysql_parse (thd=0x7f54c8000b00, rawbuf=0x7f54c8011d58 "EXECUTE stmt", length=12, parser_state=0x7f551a20c170, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7909
      #13 0x0000559d7a5a48ec in dispatch_command (command=COM_QUERY, thd=0x7f54c8000b00, packet=0x7f54c8008321 "", packet_length=12, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1843
      #14 0x0000559d7a5a2f36 in do_command (thd=0x7f54c8000b00) at /data/src/10.4/sql/sql_parse.cc:1360
      #15 0x0000559d7a72cc47 in do_handle_one_connection (connect=0x559d7ecea290) at /data/src/10.4/sql/sql_connect.cc:1412
      #16 0x0000559d7a72c996 in handle_one_connection (arg=0x559d7ecea290) at /data/src/10.4/sql/sql_connect.cc:1316
      #17 0x0000559d7b162da3 in pfs_spawn_thread (arg=0x559d7ec2e300) at /data/src/10.4/storage/perfschema/pfs.cc:1862
      #18 0x00007f5526a0c4a4 in start_thread (arg=0x7f551a20d700) at pthread_create.c:456
      #19 0x00007f5524f54d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      The crashing alter is also there, as some intermediate thread:

      Thread 21 (Thread 0x7f551a258700 (LWP 27034)):
      #0  0x00007f5524f4d603 in select () at ../sysdeps/unix/syscall-template.S:84
      #1  0x0000559d7b1f91f2 in my_addr_resolve (ptr=0x559d7b1d75ff <my_print_stacktrace+64>, loc=0x7f551a252570) at /data/src/10.4/mysys/my_addr_resolve.c:241
      #2  0x0000559d7b1d7532 in print_with_addr_resolve (addrs=0x7f551a2525d0, n=15) at /data/src/10.4/mysys/stacktrace.c:254
      #3  0x0000559d7b1d763e in my_print_stacktrace (stack_bottom=0x7f551a257e70 "", thread_stack=299008, silent=0 '\000') at /data/src/10.4/mysys/stacktrace.c:273
      #4  0x0000559d7a908aaf in handle_fatal_signal (sig=11) at /data/src/10.4/sql/signal_handler.cc:207
      #5  <signal handler called>
      #6  0x0000559d7a69b312 in fk_prepare_copy_alter_table (thd=0x7f54d4000b00, table=0x7f54d4150e50, alter_info=0x7f551a255c50, alter_ctx=0x7f551a255130) at /data/src/10.4/sql/sql_table.cc:9020
      #7  0x0000559d7a69e209 in mysql_alter_table (thd=0x7f54d4000b00, new_db=0x7f54d40052b8, new_name=0x7f54d40056c0, create_info=0x7f551a255d10, table_list=0x7f54d4013260, alter_info=0x7f551a255c50, order_num=0, order=0x0, ignore=true) at /data/src/10.4/sql/sql_table.cc:10114
      #8  0x0000559d7a736485 in Sql_cmd_alter_table::execute (this=0x7f54d4013970, thd=0x7f54d4000b00) at /data/src/10.4/sql/sql_alter.cc:508
      #9  0x0000559d7a5b41a3 in mysql_execute_command (thd=0x7f54d4000b00) at /data/src/10.4/sql/sql_parse.cc:6099
      #10 0x0000559d7a5b98ec in mysql_parse (thd=0x7f54d4000b00, rawbuf=0x7f54d4013118 "ALTER IGNORE TABLE t1 DROP FOREIGN KEY fk, DROP FOREIGN KEY fk, ALGORITHM=COPY", length=78, parser_state=0x7f551a257170, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7909
      #11 0x0000559d7a5a48ec in dispatch_command (command=COM_QUERY, thd=0x7f54d4000b00, packet=0x7f54d419e201 "ALTER IGNORE TABLE t1 DROP FOREIGN KEY fk, DROP FOREIGN KEY fk, ALGORITHM=COPY", packet_length=78, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1843
      #12 0x0000559d7a5a2f36 in do_command (thd=0x7f54d4000b00) at /data/src/10.4/sql/sql_parse.cc:1360
      #13 0x0000559d7a72cc47 in do_handle_one_connection (connect=0x559d7ecea290) at /data/src/10.4/sql/sql_connect.cc:1412
      #14 0x0000559d7a72c996 in handle_one_connection (arg=0x559d7ecea290) at /data/src/10.4/sql/sql_connect.cc:1316
      #15 0x0000559d7b162da3 in pfs_spawn_thread (arg=0x559d7ec2df60) at /data/src/10.4/storage/perfschema/pfs.cc:1862
      #16 0x00007f5526a0c4a4 in start_thread (arg=0x7f551a258700) at pthread_create.c:456
      #17 0x00007f5524f54d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Attachments

        Issue Links

          Activity

            People

              shulga Dmitry Shulga
              elenst Elena Stepanova
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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