[MDEV-17979] Assertion `0' failed in Item::val_native upon SELECT with timestamp, NULLIF, GROUP BY Created: 2018-12-12  Updated: 2018-12-12  Resolved: 2018-12-12

Status: Closed
Project: MariaDB Server
Component/s: Temporal Types
Affects Version/s: 10.4
Fix Version/s: 10.4.1

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


 Description    

CREATE TABLE t1 (a INT, b TIMESTAMP) ENGINE=MyISAM;
 
INSERT INTO t1 VALUES (1,'2018-06-19 00:00:00');
 
SELECT NULLIF(b, 'N/A') AS f, MAX(a) FROM t1 GROUP BY f;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.4 1c53aeff5

 
mysqld: /data/src/10.4/sql/item.h:1344: virtual bool Item::val_native(THD*, Native*): Assertion `0' failed.
 
181212  2:16:39 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f9f8be6bee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x0000564e187388c2 in Item::val_native (this=0x7f9f74018b20, thd=0x7f9f74000b00, to=0x7f9f85ffbfd0) at /data/src/10.4/sql/item.h:1344
 
#9  0x0000564e18a4597c in Timestamp_or_zero_datetime_native_null::Timestamp_or_zero_datetime_native_null (this=0x7f9f85ffbfd0, thd=0x7f9f74000b00, item=0x7f9f74018b20, conv=false) at /data/src/10.4/sql/sql_type.cc:8124
 
#10 0x0000564e18a495d7 in Timestamp_or_zero_datetime_native_null::Timestamp_or_zero_datetime_native_null (this=0x7f9f85ffbfd0, thd=0x7f9f74000b00, item=0x7f9f74018b20) at /data/src/10.4/sql/sql_type.h:2407
 
#11 0x0000564e18a40431 in Type_handler::Item_send_timestamp (this=0x564e19e521b0 <type_handler_timestamp2>, item=0x7f9f74018b20, protocol=0x7f9f740010c0, buf=0x7f9f85ffc0e0) at /data/src/10.4/sql/sql_type.cc:6673
 
#12 0x0000564e18a4c7fe in Type_handler_timestamp_common::Item_send (this=0x564e19e521b0 <type_handler_timestamp2>, item=0x7f9f74018b20, protocol=0x7f9f740010c0, buf=0x7f9f85ffc0e0) at /data/src/10.4/sql/sql_type.h:5409
 
#13 0x0000564e1873869e in Item::send (this=0x7f9f74018b20, protocol=0x7f9f740010c0, buffer=0x7f9f85ffc0e0) at /data/src/10.4/sql/item.h:1032
 
#14 0x0000564e1873311c in Protocol::send_result_set_row (this=0x7f9f740010c0, row_items=0x7f9f74016e08) at /data/src/10.4/sql/protocol.cc:986
 
#15 0x0000564e187dcc2e in select_send::send_data (this=0x7f9f74016a30, items=...) at /data/src/10.4/sql/sql_class.cc:2949
 
#16 0x0000564e188be5ae in end_send_group (join=0x7f9f74016a58, join_tab=0x0, end_of_records=true) at /data/src/10.4/sql/sql_select.cc:20718
 
#17 0x0000564e188ba1a8 in do_select (join=0x7f9f74016a58, procedure=0x0) at /data/src/10.4/sql/sql_select.cc:18889
 
#18 0x0000564e18892eb1 in JOIN::exec_inner (this=0x7f9f74016a58) at /data/src/10.4/sql/sql_select.cc:4094
 
#19 0x0000564e188922f2 in JOIN::exec (this=0x7f9f74016a58) at /data/src/10.4/sql/sql_select.cc:3888
 
#20 0x0000564e188935b1 in mysql_select (thd=0x7f9f74000b00, tables=0x7f9f74015a18, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7f9f74016180, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f9f74016a30, unit=0x7f9f740049c0, select_lex=0x7f9f74014e88) at /data/src/10.4/sql/sql_select.cc:4293
 
#21 0x0000564e18884ebd in handle_select (thd=0x7f9f74000b00, lex=0x7f9f740048f8, result=0x7f9f74016a30, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:385
 
#22 0x0000564e1884f0e7 in execute_sqlcom_select (thd=0x7f9f74000b00, all_tables=0x7f9f74015a18) at /data/src/10.4/sql/sql_parse.cc:6566
 
#23 0x0000564e188456e2 in mysql_execute_command (thd=0x7f9f74000b00) at /data/src/10.4/sql/sql_parse.cc:3775
 
#24 0x0000564e18852ef2 in mysql_parse (thd=0x7f9f74000b00, rawbuf=0x7f9f74014db8 "SELECT NULLIF(b, 'N/A') AS f, MAX(a) FROM t1 GROUP BY f", length=55, parser_state=0x7f9f85ffd600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8103
 
#25 0x0000564e1884011c in dispatch_command (command=COM_QUERY, thd=0x7f9f74000b00, packet=0x7f9f7400b421 "", packet_length=55, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1850
 
#26 0x0000564e1883eb40 in do_command (thd=0x7f9f74000b00) at /data/src/10.4/sql/sql_parse.cc:1395
 
#27 0x0000564e189aaa2e in do_handle_one_connection (connect=0x564e1ba0b0a0) at /data/src/10.4/sql/sql_connect.cc:1402
 
#28 0x0000564e189aa7b2 in handle_one_connection (arg=0x564e1ba0b0a0) at /data/src/10.4/sql/sql_connect.cc:1308
 
#29 0x0000564e18e6811e in pfs_spawn_thread (arg=0x564e1b96b190) at /data/src/10.4/storage/perfschema/pfs.cc:1862
 
#30 0x00007f9f8d927494 in start_thread (arg=0x7f9f85ffe700) at pthread_create.c:333
 
#31 0x00007f9f8bf2893f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Not reproducible on 10.3.
No visible effect on a non-debug build.

 Comments   
Comment by Alexander Barkov [ 2018-12-12 ]

The problem happens because the SELECT..GROUP query uses Item_copy_string, which also causes this problem on the near-DST-change timestamp values:

SET time_zone='+00:00';
 
CREATE OR REPLACE TABLE t1 (a INT, ts TIMESTAMP) ENGINE=MyISAM;
 
INSERT INTO t1 VALUES (1, FROM_UNIXTIME(1288481126) /*winter time in Moscow*/);
 
SET time_zone='Europe/Moscow';
 
CREATE OR REPLACE TABLE t2 AS SELECT ts, COALESCE(ts) AS cts FROM t1 GROUP BY cts;
 
SELECT ts, cts, UNIX_TIMESTAMP(ts) AS uts, UNIX_TIMESTAMP(cts) AS ucts FROM t2;


+---------------------+---------------------+------------+------------+
 
| ts                  | cts                 | uts        | ucts       |
 
+---------------------+---------------------+------------+------------+
 
| 2010-10-31 02:25:26 | 2010-10-31 02:25:26 | 1288481126 | 1288477526 |
 
+---------------------+---------------------+------------+------------+

Notice, the ucts value is wrong (while the uts value is correct). Round trip conversion TIMESTAMP->string->TIMESTAMP lost the precise timestamp value and chose the summer time corresponding to '2010-10-31 02:25:26' instead of the winter time corresponding to '2010-10-31 02:25:26'.

Adding a new class Item_copy_timestamp should fix this problem.

Generated at Thu Feb 08 08:40:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.