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

Assertion `is_valid_value_slow()' failed in Time::adjust_time_range_or_invalidate

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.4.0
    • 10.4.0
    • Temporal Types
    • None

    Description

      set sql_mode='';
      		 
       
      		 
      CREATE TABLE t1 (d1 date, t1 time, KEY t1 (t1));
      		 
      INSERT INTO t1 VALUES ('1982-12-19','08:16:31'),('1981-04-19','21:52:59'),('1971-06-09','07:15:44'),('2007-08-15','03:55:02'),('1993-06-05','04:17:51'),('2034-07-01','17:31:12'),('1998-08-24','08:09:27'),('1991-01-15','01:14:07'),('2001-02-25','10:41:28'),('1974-06-24','10:21:58'),('1977-04-21','16:38:05'),('1981-12-03','01:24:42'),('1972-06-15','20:19:16'),('1989-08-10','08:53:47'),('2018-05-19','15:06:49'),('1984-01-12','15:56:11'),('2013-01-23','04:16:16'),('2000-06-10','02:06:44'),('1995-01-03','04:51:38');
      		 
       
      		 
      CREATE TABLE t2 (d1 date );
      		 
      INSERT INTO t2 VALUES ('2018-06-01'),('1979-10-25'),('1974-08-22'),('1980-06-17');
      		 
       
      		 
      UPDATE (t1 JOIN t2 ON (t2.d1 = t1.t1)) SET t1.d1 = '2018-07-07' WHERE (t1.d1 > 70 );
      		 
       
      		 
      drop table t1,t2;

      mysqld: /git/10.4/sql/sql_type.h:707: void Time::adjust_time_range_or_invalidate(int*): Assertion `is_valid_value_slow()' failed.

       10.4 befc09f00263d5375b2bb2e
      		 
      180814 11:46:16 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      linux/raise.c:54(__GI_raise)[0x7f6faebda428]
      		 
      stdlib/abort.c:91(__GI_abort)[0x7f6faebdc02a]
      		 
      assert/assert.c:92(__assert_fail_base)[0x7f6faebd2bd7]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f6faebd2c82]
      		 
      sql/sql_type.h:708(Time::adjust_time_range_or_invalidate(int*))[0x561a41ea927a]
      		 
      sql/sql_type.cc:410(Time::make_from_datetime_with_days_diff(int*, st_mysql_time const*, long))[0x561a41e85e50]
      		 
      sql/sql_type.cc:435(Time::make_from_datetime(int*, st_mysql_time const*, long))[0x561a41e861fe]
      		 
      sql/sql_type.cc:463(Time::Time(int*, st_mysql_time const*, long))[0x561a41e8661c]
      		 
      sql/field.cc:5745(Field_time::store_time_dec(st_mysql_time const*, unsigned int))[0x561a42095d67]
      		 
      sql/field_conv.cc:446(Field_time::do_field_time(Copy_field*))[0x561a420dcce5]
      		 
      sql/field_conv.cc:248(do_copy_null(Copy_field*))[0x561a420da5a6]
      		 
      sql/sql_select.h:1932(store_key_field::copy_inner())[0x561a41b83609]
      		 
      sql/sql_select.h:1872(store_key::copy())[0x561a41b83151]
      		 
      sql/sql_select.cc:22787(cp_buffer_from_ref(THD*, TABLE*, st_table_ref*))[0x561a41b55352]
      		 
      sql/sql_select.cc:19999(join_read_always_key(st_join_table*))[0x561a41b417e2]
      		 
      sql/sql_select.cc:19247(sub_select(JOIN*, st_join_table*, bool))[0x561a41b3c8af]
      		 
      sql/sql_select.cc:19470(evaluate_join_record(JOIN*, st_join_table*, int))[0x561a41b3de64]
      		 
      sql/sql_select.cc:19289(sub_select(JOIN*, st_join_table*, bool))[0x561a41b3d0e6]
      		 
      sql/sql_select.cc:18790(do_select(JOIN*, Procedure*))[0x561a41b3af07]
      		 
      sql/sql_select.cc:4076(JOIN::exec_inner())[0x561a41ada43b]
      		 
      sql/sql_select.cc:3871(JOIN::exec())[0x561a41ad8180]
      		 
      sql/sql_select.cc:4277(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x561a41adb50b]
      		 
      sql/sql_update.cc:1766(mysql_multi_update(THD*, TABLE_LIST*, List<Item>*, List<Item>*, Item*, unsigned long long, enum_duplicates, bool, st_select_lex_unit*, st_select_lex*, multi_update**))[0x561a41c84b4a]
      		 
      sql/sql_parse.cc:4639(mysql_execute_command(THD*))[0x561a41a2e453]
      		 
      sql/sql_parse.cc:8064(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x561a41a43ca5]
      		 
      sql/sql_parse.cc:1849(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x561a41a1edcb]
      		 
      sql/sql_parse.cc:1392(do_command(THD*))[0x561a41a1bf63]
      		 
      sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x561a41d6c768]
      		 
      sql/sql_connect.cc:1309(handle_one_connection)[0x561a41d6c145]
      		 
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f6faf8176ba]
      		 
      x86_64/clone.S:111(clone)[0x7f6faecac41d]

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15881 Assertion `is_valid_value_slow()' failed in Datetime::Datetime or corrupt data after ALTER with indexed persistent column

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            elenst Elena Stepanova added a comment -

            It has something to do with 

            commit d2bba4ce258eb80117771fb6c3782348ce4ae924
            		 
            Author: Alexander Barkov <bar@mariadb.com>
            		 
            Date:   Thu Aug 9 18:50:33 2018 +0400
            		 
             
            		 
                MDEV-16928 Move MYSQL_TIME initialization from Field_xxx::store_time_dec() to new constructors Time() and Datetime()

            elenst Elena Stepanova added a comment - It has something to do with commit d2bba4ce258eb80117771fb6c3782348ce4ae924 Author: Alexander Barkov <bar@mariadb.com> Date: Thu Aug 9 18:50:33 2018 +0400   MDEV-16928 Move MYSQL_TIME initialization from Field_xxx::store_time_dec() to new constructors Time() and Datetime()
            bar Alexander Barkov added a comment -

            The reason of problem is repeatable in 10.3.
            The second call for unpack_time() returns with this wrong value:

            $1 =

            {year = 34, month = 0, day = 0, hour = 720, minute = 0, second = 0, second_part = 0, neg = 1 '\001', time_type = MYSQL_TIMESTAMP_TIME}

            10.4 catches this wrong value by a new assert, 10.3 does not.

            bar Alexander Barkov added a comment - The reason of problem is repeatable in 10.3. The second call for unpack_time() returns with this wrong value: $1 = {year = 34, month = 0, day = 0, hour = 720, minute = 0, second = 0, second_part = 0, neg = 1 '\001', time_type = MYSQL_TIMESTAMP_TIME} 10.4 catches this wrong value by a new assert, 10.3 does not.
            elenst Elena Stepanova added a comment -

            bar,

            Would it mean that MDEV-15881 is actually the same problem and can be closed as a duplicate?

            elenst Elena Stepanova added a comment - bar , Would it mean that MDEV-15881 is actually the same problem and can be closed as a duplicate?
            bar Alexander Barkov added a comment -

            elenst MDEV-15881 looks like a separate issue. I added a lot of new asserts to catch situations when a MYSQL_TIME structure is initialized improperly. It's very likely there will be new crashes on asserts soon.

            bar Alexander Barkov added a comment - elenst MDEV-15881 looks like a separate issue. I added a lot of new asserts to catch situations when a MYSQL_TIME structure is initialized improperly. It's very likely there will be new crashes on asserts soon.

            People

              bar Alexander Barkov
              alice Alice Sherepa
              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.