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

crash when I insert on a table

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.3.11
    • N/A
    • N/A
    • None
    • centos 7

    Description

      it is not related to any engine, for if change the engine on the same table it crashes anyway. this is the issue that makes Mariadb crash

      CREATE TABLE client_1.test (
        number bigint(20) NOT NULL,
        lrn bigint(20) NOT NULL DEFAULT 0,
        source varchar(15) NOT NULL DEFAULT 'reverse(substring_index(reverse(user()),''@'',1))',
        PRIMARY KEY (number)
      )
      ENGINE = INNODB,
      AVG_ROW_LENGTH = 2048,
      CHARACTER SET latin1,
      COLLATE latin1_swedish_ci;
      

      when I include that default, it inserts fine, if I do a replace on the same number, it crashes.
      That default is meant to capture the IP address of the user, which I use for billing.

      Again, the engine is not the issue.

       
       
      pure virtual method called
      terminate called without an active exception
      181212 17:31:18 [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.3.11-MariaDB
      key_buffer_size=134217728
      read_buffer_size=131072
      max_used_connections=5
      max_threads=65546
      thread_count=12
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 25302073 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x7fb13846b008
      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 = 0x7fc8f1c3cc60 thread_stack 0x30000
      /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x560e80e5561e]
      /usr/sbin/mysqld(handle_fatal_signal+0x357)[0x560e808f63a7]
      /lib64/libpthread.so.0(+0xf5d0)[0x7fc8f670d5d0]
      /lib64/libc.so.6(gsignal+0x37)[0x7fc8f49e1207]
      /lib64/libc.so.6(abort+0x148)[0x7fc8f49e28f8]
      /lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x165)[0x7fc8f50da7d5]
      /lib64/libstdc++.so.6(+0x5e746)[0x7fc8f50d8746]
      /lib64/libstdc++.so.6(+0x5e773)[0x7fc8f50d8773]
      /lib64/libstdc++.so.6(+0x5f2df)[0x7fc8f50d92df]
      /usr/sbin/mysqld(_ZN16Item_func_or_sum4walkEM4ItemFbPvEbS1_+0x67)[0x560e806d04e7]
      /usr/sbin/mysqld(_ZN16Item_func_or_sum4walkEM4ItemFbPvEbS1_+0x67)[0x560e806d04e7]
      /usr/sbin/mysqld(_Z21fix_session_vcol_exprP3THDP19Virtual_column_info+0x3c)[0x560e807ca3fc]
      /usr/sbin/mysqld(_Z11lock_tablesP3THDP10TABLE_LISTjj+0x452)[0x560e806c9732]
      /usr/sbin/mysqld(_Z20open_and_lock_tablesP3THDRK14DDL_options_stP10TABLE_LISTbjP19Prelocking_strategy+0x8a)[0x560e806cadea]
      /usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0xf6)[0x560e806f8d46]
      /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2008)[0x560e807220d8]
      sql/item.h:2190(Item_args::walk_args(bool (Item::*)(void*), bool, void*))[0x560e807292db]
      sql/item.h:2190(Item_args::walk_args(bool (Item::*)(void*), bool, void*))[0x560e8072be35]
      sql/table.cc:2888(fix_session_vcol_expr(THD*, Virtual_column_info*))[0x560e8072cc9e]
      sql/sql_base.cc:5182(fix_all_session_vcol_exprs)[0x560e808375fb]
      sql/sql_base.cc:5005(open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*))[0x560e808cb540]
      /lib64/libpthread.so.0(+0x7dd5)[0x7fc8f6705dd5]
      /lib64/libc.so.6(clone+0x6d)[0x7fc8f4aa8ead]
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x7fb138546020): replace dataqueue(number) values('7274433019')
      Connection ID (thread ID): 48
      Status: NOT_KILLED
       
      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
       
      The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
      information that should help you find out what is causing the crash.
      Wed Dec 12 17:31:37 2018 PerconaFT recovery starting in env /var/lib/mysql/
      Wed Dec 12 17:31:37 2018 PerconaFT recovery scanning backward from 2177833191
      Wed Dec 12 17:31:37 2018 PerconaFT recovery bw_end_checkpoint at 2177833191 timestamp 1544635835242697 xid 2177833187 (bw_newer)
      Wed Dec 12 17:31:37 2018 PerconaFT recovery bw_begin_checkpoint at 2177833187 timestamp 1544635835242623 (bw_between)
      Wed Dec 12 17:31:37 2018 PerconaFT recovery turning around at begin checkpoint 2177833187 time 74
      Wed Dec 12 17:31:37 2018 PerconaFT recovery starts scanning forward to 2177833191 from 2177833187 left 4 (fw_between)
      Wed Dec 12 17:31:37 2018 PerconaFT recovery closing 2 dictionaries
      Wed Dec 12 17:31:37 2018 PerconaFT recovery making a checkpoint
      Wed Dec 12 17:31:37 2018 PerconaFT recovery done
      

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              philip_38 Philip orleans
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.