[MDEV-10787] Assertion `ltime->neg == 0' failed in void date_to_datetime(MYSQL_TIME*) Created: 2016-09-09  Updated: 2016-12-07  Resolved: 2016-12-07

Status: Closed
Project: MariaDB Server
Component/s: Temporal Types
Affects Version/s: 10.0, 10.1, 10.2
Fix Version/s: 10.0.29, 10.1.20, 10.2.3

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Sprint: 10.1.20

 Description   

Stack trace from 10.0 b34d7fba31c

mysqld: /data/src/10.0/sql/sql_time.h:79: void date_to_datetime(MYSQL_TIME*): Assertion `ltime->neg == 0' failed.
160912 21:04:03 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fba28db4312 in __GI___assert_fail (assertion=0xf4e681 "ltime->neg == 0", file=0xf4e609 "/data/src/10.0/sql/sql_time.h", line=79, function=0xf4f800 <date_to_datetime(st_mysql_time*)::__PRETTY_FUNCTION__> "void date_to_datetime(MYSQL_TIME*)") at assert.c:101
#8  0x00000000008f7fde in date_to_datetime (ltime=0x7fba2b077d10) at /data/src/10.0/sql/sql_time.h:79
#9  0x00000000008f0ff7 in Item_temporal_hybrid_func::fix_temporal_type (this=0x7fba214fa3b0, ltime=0x7fba2b077d10) at /data/src/10.0/sql/item_timefunc.cc:1530
#10 0x00000000008f10ae in Item_temporal_hybrid_func::val_str_ascii (this=0x7fba214fa3b0, str=0x7fba2b077f40) at /data/src/10.0/sql/item_timefunc.cc:1550
#11 0x00000000008b8096 in Item_func::val_str_from_val_str_ascii (this=0x7fba214fa3b0, str=0x7fba2b077f40, str2=0x7fba214fa488) at /data/src/10.0/sql/item_strfunc.cc:83
#12 0x00000000008f7412 in Item_temporal_hybrid_func::val_str (this=0x7fba214fa3b0, str=0x7fba2b077f40) at /data/src/10.0/sql/item_timefunc.h:552
#14 0x00000000008540e9 in Item::send (this=0x7fba214fa600, protocol=0x7fba243dd5f8, buffer=0x7fba2b077f40) at /data/src/10.0/sql/item.cc:6509
#15 0x000000000059f1d8 in Protocol::send_result_set_row (this=0x7fba243dd5f8, row_items=0x7fba243e1218) at /data/src/10.0/sql/protocol.cc:912
#16 0x000000000060d779 in select_send::send_data (this=0x7fba214faee0, items=...) at /data/src/10.0/sql/sql_class.cc:2573
#17 0x00000000006a9d2b in end_send (join=0x7fba214faf00, join_tab=0x7fba217ae3b0, end_of_records=false) at /data/src/10.0/sql/sql_select.cc:18972
#18 0x00000000006a7ab4 in evaluate_join_record (join=0x7fba214faf00, join_tab=0x7fba217ae088, error=0) at /data/src/10.0/sql/sql_select.cc:18065
#19 0x00000000006a73d6 in sub_select (join=0x7fba214faf00, join_tab=0x7fba217ae088, end_of_records=false) at /data/src/10.0/sql/sql_select.cc:17843
#20 0x00000000006a6c49 in do_select (join=0x7fba214faf00, fields=0x7fba243e1218, table=0x0, procedure=0x0) at /data/src/10.0/sql/sql_select.cc:17505
#21 0x0000000000683d40 in JOIN::exec_inner (this=0x7fba214faf00) at /data/src/10.0/sql/sql_select.cc:3084
#22 0x0000000000681216 in JOIN::exec (this=0x7fba214faf00) at /data/src/10.0/sql/sql_select.cc:2373
#23 0x000000000068457e in mysql_select (thd=0x7fba243dd070, rref_pointer_array=0x7fba243e1378, tables=0x7fba214fa848, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fba214faee0, unit=0x7fba243e0a10, select_lex=0x7fba243e1100) at /data/src/10.0/sql/sql_select.cc:3308
#24 0x000000000067a93a in handle_select (thd=0x7fba243dd070, lex=0x7fba243e0948, result=0x7fba214faee0, setup_tables_done_option=0) at /data/src/10.0/sql/sql_select.cc:373
#25 0x000000000064f197 in execute_sqlcom_select (thd=0x7fba243dd070, all_tables=0x7fba214fa848) at /data/src/10.0/sql/sql_parse.cc:5294
#26 0x00000000006476c2 in mysql_execute_command (thd=0x7fba243dd070) at /data/src/10.0/sql/sql_parse.cc:2563
#27 0x0000000000651e18 in mysql_parse (thd=0x7fba243dd070, rawbuf=0x7fba214fa088 "SELECT REPLACE( ADDDATE( d, INTERVAL 0.6732771076944444 HOUR_SECOND ), '2', 'x' ) FROM t1", length=89, parser_state=0x7fba2b079650) at /data/src/10.0/sql/sql_parse.cc:6576
#28 0x0000000000644918 in dispatch_command (command=COM_QUERY, thd=0x7fba243dd070, packet=0x7fba243d3071 "", packet_length=89) at /data/src/10.0/sql/sql_parse.cc:1309
#29 0x0000000000643bdb in do_command (thd=0x7fba243dd070) at /data/src/10.0/sql/sql_parse.cc:999
#30 0x0000000000761efa in do_handle_one_connection (thd_arg=0x7fba243dd070) at /data/src/10.0/sql/sql_connect.cc:1378
#31 0x0000000000761c6c in handle_one_connection (arg=0x7fba243dd070) at /data/src/10.0/sql/sql_connect.cc:1293
#32 0x00000000009faa88 in pfs_spawn_thread (arg=0x7fba22d91370) at /data/src/10.0/storage/perfschema/pfs.cc:1860
#33 0x00007fba2acb60a4 in start_thread (arg=0x7fba2b07a700) at pthread_create.c:309
#34 0x00007fba28e6e87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

CREATE TABLE t1 (d DATE);
INSERT INTO t1 VALUES ('2005-07-20'),('2012-12-21');
SELECT REPLACE( ADDDATE( d, INTERVAL 0.6732771076944444 HOUR_SECOND ), '2', 'x' ) FROM t1;

10.2 is also affected.



 Comments   
Comment by Alexander Barkov [ 2016-12-06 ]

The same problem happens with a string value in quotes:

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (d DATE);
INSERT INTO t1 VALUES ('2005-07-20');
SELECT REPLACE( ADDDATE( d, INTERVAL '0.6732771076944444' HOUR_SECOND ), '2', 'x' ) FROM t1;

The same problem happens with CAST instead of REPLACE:

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (d DATE);
INSERT INTO t1 VALUES ('2005-07-20'),('2012-12-21');
SELECT CAST(ADDDATE( d, INTERVAL 0.6732771076944444 HOUR_SECOND) AS CHAR) FROM t1;

MariaDB-5.5 returned this result

+--------------------------------------------------------------------+
| CAST(ADDDATE( d, INTERVAL 0.6732771076944444 HOUR_SECOND) AS CHAR) |
+--------------------------------------------------------------------+
| 7200-05-05 18:59:02                                                |
| 7192-12-02 18:59:02                                                |
+--------------------------------------------------------------------+

Which looks incorrect. The smaller DATE value returns the bigger result.

The same crash happens with:

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (d DATE);
INSERT INTO t1 VALUES ('2005-07-20'),('2012-12-21');
SELECT CAST(ADDDATE( d, INTERVAL 6732771076944444 SECOND) AS CHAR) FROM t1;

Generated at Thu Feb 08 07:44:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.