Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-3841 LevelDB storage engine
  3. MDEV-3966

[recreate?] Assorted server crashes on a scenario involving creating and populating a LevelDB table

    XMLWordPrintable

Details

    • Technical task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • OpenSUSE 12.2 32-bit

    Description

      The test case provided below looks heavily excessive, but removing even one seemingly unrelated line changes the result, at least on my machine. I already have 3 different outcomes, with totally different stack traces (also provided below). Apparently, it's either timing or the length of some statements, even removing backticks seems to affect the result. Valgrind produces too much noise, but if you can't reproduce any of the crashes, please try --valgrind-mysqld to see if it helps to understand the issue(s).

      MTR test case:

       
      --connect (con1,localhost,root,,)
      SELECT CONNECTION_ID() AS con1;
       
      --connect (con2,localhost,root,,test)
      SELECT CONNECTION_ID() AS con2;
       
      SELECT @@global.log_bin = 'ON' AND @@global.binlog_format = 'STATEMENT';
      DROP TABLE IF EXISTS t1;
      SELECT 1 FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE TABLE_NAME='t1';
       
      --error ER_NO_SUCH_TABLE
      SHOW CREATE TABLE t1;
       
      SELECT REPLACE("CREATE TABLE `t1` (
         `b` binary(1) DEFAULT NULL,
         `b20` binary(20) NOT NULL,
         `v16` varbinary(16) DEFAULT NULL,
         `v128` varbinary(128) DEFAULT NULL,
         UNIQUE KEY `b20` (`b20`)
       ) ENGINE=MyISAM DEFAULT CHARSET=latin1",'MyISAM','LevelDB');
       
      --error ER_BAD_TABLE_ERROR
      DROP TABLE `t1`;
       
      CREATE TABLE `t1` (
         `b` binary(1) DEFAULT NULL,
         `b20` binary(20) NOT NULL,
         `v16` varbinary(16) DEFAULT NULL,
         `v128` varbinary(128) DEFAULT NULL,
         UNIQUE KEY `b20` (`b20`)
       ) ENGINE=LevelDB DEFAULT CHARSET=latin1;
      SHOW INDEX IN t1;
      SHOW INDEXES IN t1 WHERE `Null`='YES';
      SELECT COUNT(*) > 1 FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE TABLE_NAME='t1';
      DROP TABLE `t1`;
      CREATE TABLE `t1` (
         `b` binary(1) DEFAULT NULL,
         `b20` binary(20) NOT NULL,
         `v16` varbinary(16) DEFAULT NULL,
         `v128` varbinary(128) DEFAULT NULL,
         PRIMARY KEY (`b20`)
       ) ENGINE=LevelDB DEFAULT CHARSET=latin1;
      SHOW INDEX IN t1;
      INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b');

      Stack trace 1 (one that I'm usually getting with this exact test scenario, not changing a single line):

      #3  0x08314cba in handle_fatal_signal (sig=6) at mysql-5.6-leveldb/sql/signal_handler.cc:248
      #4  <signal handler called>
      #5  0xb777f430 in __kernel_vsyscall ()
      #6  0xb73fd31f in raise () from /lib/libc.so.6
      #7  0xb73fec03 in abort () from /lib/libc.so.6
      #8  0xb7441079 in __malloc_assert () from /lib/libc.so.6
      #9  0xb7443ecf in _int_malloc () from /lib/libc.so.6
      #10 0xb7445ac8 in malloc () from /lib/libc.so.6
      #11 0xb760f545 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
      #12 0xb7674265 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/libstdc++.so.6
      #13 0xb76755cf in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) () from /usr/lib/libstdc++.so.6
      #14 0xb76756fd in std::string::reserve(unsigned int) () from /usr/lib/libstdc++.so.6
      #15 0xb7675a4a in std::string::append(char const*, unsigned int) () from /usr/lib/libstdc++.so.6
      #16 0xb772af96 in leveldb::PutLengthPrefixedSlice(std::string*, leveldb::Slice const&) () from leveldb-1.7.0/libleveldb.so.1
      #17 0xb7722e4b in leveldb::WriteBatch::Put(leveldb::Slice const&, leveldb::Slice const&) () from leveldb-1.7.0/libleveldb.so.1
      #18 0x0891c1d7 in ha_leveldb::write_row (this=0xaf7254d0, buf=0xaf725688 "\370achar1") at mysql-5.6-leveldb/storage/leveldb/ha_leveldb.cc:760
      #19 0x0825730a in handler::ha_write_row (this=0xaf7254d0, buf=0xaf725688 "\370achar1") at mysql-5.6-leveldb/sql/handler.cc:7131
      #20 0x0838c0aa in write_record (thd=0x9570328, table=0xaf7230c8, info=0xaf6cc9a0, update=0xaf6cc9fc) at mysql-5.6-leveldb/sql/sql_insert.cc:1858
      #21 0x0838a24a in mysql_insert (thd=0x9570328, table_list=0xaf7189b0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at mysql-5.6-leveldb/sql/sql_insert.cc:1036
      #22 0x083a7373 in mysql_execute_command (thd=0x9570328) at mysql-5.6-leveldb/sql/sql_parse.cc:3344
      #23 0x083ae558 in mysql_parse (thd=0x9570328, rawbuf=0xaf7187b8 "INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b')", length=190, parser_state=0xaf6cd758) at mysql-5.6-leveldb/sql/sql_parse.cc:6097
      #24 0x083a2f3e in dispatch_command (command=COM_QUERY, thd=0x9570328, packet=0x9572f51 "INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b')", packet_length=190) at mysql-5.6-leveldb/sql/sql_parse.cc:1312
      #25 0x083a236e in do_command (thd=0x9570328) at mysql-5.6-leveldb/sql/sql_parse.cc:1036
      #26 0x08371d29 in do_handle_one_connection (thd_arg=0x9570328) at mysql-5.6-leveldb/sql/sql_connect.cc:969
      #27 0x083718d2 in handle_one_connection (arg=0x9570328) at mysql-5.6-leveldb/sql/sql_connect.cc:885
      #28 0x08650747 in pfs_spawn_thread (arg=0x95279b0) at mysql-5.6-leveldb/storage/perfschema/pfs.cc:1853
      #29 0xb774ae32 in start_thread () from /lib/libpthread.so.0
      #30 0xb74b98ee in clone () from /lib/libc.so.6

      Stack trace 2 (I was getting it sometimes with basically the same scenario, just removing some queries like SHOW and SELECT):

       <signal handler called>
      #5  0xb7760430 in __kernel_vsyscall ()
      #6  0xb73de31f in raise () from /lib/libc.so.6
      #7  0xb73dfc03 in abort () from /lib/libc.so.6
      #8  0xb741c335 in __libc_message () from /lib/libc.so.6
      #9  0xb7422ac2 in malloc_printerr () from /lib/libc.so.6
      #10 0xb75ee25f in operator delete(void*) () from /usr/lib/libstdc++.so.6
      #11 0x083072e0 in MDL_ticket::~MDL_ticket (this=0xa162db8, __in_chrg=<optimized out>) at mysql-5.6-leveldb/sql/mdl.h:556
      #12 0x0830362c in MDL_ticket::destroy (ticket=0xa162db8) at mysql-5.6-leveldb/sql/mdl.cc:1194
      #13 0x08305672 in MDL_context::release_lock (this=0xa173580, duration=MDL_STATEMENT, ticket=0xa162db8) at mysql-5.6-leveldb/sql/mdl.cc:2708
      #14 0x083057ae in MDL_context::release_locks_stored_before (this=0xa173580, duration=MDL_STATEMENT, sentinel=0x0) at mysql-5.6-leveldb/sql/mdl.cc:2755
      #15 0x08305b3e in MDL_context::release_transactional_locks (this=0xa173580) at mysql-5.6-leveldb/sql/mdl.cc:2903
      #16 0x083abf07 in mysql_execute_command (thd=0xa1734f8) at mysql-5.6-leveldb/sql/sql_parse.cc:4933
      #17 0x083ae558 in mysql_parse (thd=0xa1734f8, rawbuf=0xa17e308 "INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b')", length=190, parser_state=0xaf6fe758) at mysql-5.6-leveldb/sql/sql_parse.cc:6097
      #18 0x083a2f3e in dispatch_command (command=COM_QUERY, thd=0xa1734f8, packet=0xa176121 "INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b')", packet_length=190) at mysql-5.6-leveldb/sql/sql_parse.cc:1312
      #19 0x083a236e in do_command (thd=0xa1734f8) at mysql-5.6-leveldb/sql/sql_parse.cc:1036
      #20 0x08371d29 in do_handle_one_connection (thd_arg=0xa1734f8) at mysql-5.6-leveldb/sql/sql_connect.cc:969
      #21 0x083718d2 in handle_one_connection (arg=0xa1734f8) at mysql-5.6-leveldb/sql/sql_connect.cc:885
      #22 0x08650747 in pfs_spawn_thread (arg=0xa159ed8) at mysql-5.6-leveldb/storage/perfschema/pfs.cc:1853
      #23 0xb772be32 in start_thread () from /lib/libpthread.so.0

      Stack trace 3 (I was getting it sometimes after reducing the scenario even further, to almost nothing)

      /lib/libc.so.6(+0x72ac2)[0xb73a4ac2]
      /usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb757025f]
      mysql-5.6-leveldb/sql/mysqld(table_cache_free_entry+0x11)[0x8455926]
      mysql-5.6-leveldb/sql/mysqld(my_hash_delete+0x3e3)[0x85eed54]
      mysql-5.6-leveldb/sql/mysqld(_ZN11Table_cache12remove_tableEP5TABLE+0xd4)[0x83568f6]
      mysql-5.6-leveldb/sql/mysqld(_ZN11Table_cache22free_all_unused_tablesEv+0x2e)[0x8455a44]
      mysql-5.6-leveldb/sql/mysqld(_ZN19Table_cache_manager22free_all_unused_tablesEv+0x2d)[0x8456081]
      mysql-5.6-leveldb/sql/mysqld(_Z19close_cached_tablesP3THDP10TABLE_LISTbm+0xc8)[0x83469b3]
      mysql-5.6-leveldb/sql/mysqld(_Z24table_def_start_shutdownv+0x54)[0x8345a34]
      mysql-5.6-leveldb/sql/mysqld[0x8236550]
      mysql-5.6-leveldb/sql/mysqld(_Z10unireg_endv+0x12)[0x82361d5]
      mysql-5.6-leveldb/sql/mysqld[0x8236111]
      mysql-5.6-leveldb/sql/mysqld(kill_server_thread+0x17)[0x823613b]
      mysql-5.6-leveldb/sql/mysqld(pfs_spawn_thread+0x13e)[0x8650747]
      /lib/libpthread.so.0(+0x6e32)[0xb76ade32]
      /lib/libc.so.6(clone+0x5e)[0xb741c8ee]

      revision-id: psergey@askmonty.org-20121221181426-m94ou0fykf40dfno
      date: 2012-12-21 22:14:26 +0400
      build-date: 2012-12-22 15:20:00 +0400
      revno: 4477
      branch: mysql-5.6-leveldb

      Built with cmake . -DCMAKE_BUILD_TYPE=Debug && make, no other cmake options.

      Attachments

        Issue Links

          Activity

            People

              psergei Sergei Petrunia
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.