[MDEV-15955]  Assertion `field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG' failed in Protocol_text::store_longlong Created: 2018-04-20  Updated: 2019-08-20  Resolved: 2019-08-16

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 5.5, 10.1
Fix Version/s: 5.5.66, 10.1.42

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


 Description   

CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2);
SELECT @a := 1 FROM t1 ORDER BY STRCMP(STDDEV_SAMP(a), 'bar');
 
# Cleanup
DROP TABLE t1;

10.1 f2e14517

mysqld: /data/src/10.1/sql/protocol.cc:1114: virtual bool Protocol_text::store_longlong(longlong, bool): Assertion `field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG' failed.
190303 18:14:39 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f0c4894dee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000056197233cd43 in Protocol_text::store_longlong (this=0x7f0c418d5600, from=1, unsigned_flag=false) at /data/src/10.1/sql/protocol.cc:1113
#9  0x00005619726592f6 in Item::send (this=0x7f0c3fc47150, protocol=0x7f0c418d5600, buffer=0x7f0c4a9ced60) at /data/src/10.1/sql/item.cc:6434
#10 0x000056197233c332 in Protocol::send_result_set_row (this=0x7f0c418d5600, row_items=0x7f0c3fc446a8) at /data/src/10.1/sql/protocol.cc:914
#11 0x00005619723b4e28 in select_send::send_data (this=0x7f0c3fc44288, items=...) at /data/src/10.1/sql/sql_class.cc:2748
#12 0x000056197246222a in end_send_group (join=0x7f0c3fc46658, join_tab=0x7f0c3fc470b0, end_of_records=true) at /data/src/10.1/sql/sql_select.cc:19761
#13 0x000056197245eee8 in sub_select (join=0x7f0c3fc46658, join_tab=0x7f0c3fc46d68, end_of_records=true) at /data/src/10.1/sql/sql_select.cc:18431
#14 0x000056197245e9c0 in do_select (join=0x7f0c3fc46658, fields=0x7f0c3fc446a8, table=0x0, procedure=0x0) at /data/src/10.1/sql/sql_select.cc:18137
#15 0x00005619724391ba in JOIN::exec_inner (this=0x7f0c3fc442a8) at /data/src/10.1/sql/sql_select.cc:3275
#16 0x000056197243644b in JOIN::exec (this=0x7f0c3fc442a8) at /data/src/10.1/sql/sql_select.cc:2562
#17 0x00005619724399e1 in mysql_select (thd=0x7f0c418d5070, rref_pointer_array=0x7f0c418d9560, tables=0x7f0c3fc436f0, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x7f0c3fc44170, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f0c3fc44288, unit=0x7f0c418d8bb8, select_lex=0x7f0c418d92b8) at /data/src/10.1/sql/sql_select.cc:3499
#18 0x000056197242f09a in handle_select (thd=0x7f0c418d5070, lex=0x7f0c418d8af0, result=0x7f0c3fc44288, setup_tables_done_option=0) at /data/src/10.1/sql/sql_select.cc:388
#19 0x00005619723fea2f in execute_sqlcom_select (thd=0x7f0c418d5070, all_tables=0x7f0c3fc436f0) at /data/src/10.1/sql/sql_parse.cc:5950
#20 0x00005619723f4e04 in mysql_execute_command (thd=0x7f0c418d5070) at /data/src/10.1/sql/sql_parse.cc:2995
#21 0x0000561972402673 in mysql_parse (thd=0x7f0c418d5070, rawbuf=0x7f0c3fc43088 "SELECT @a := 1 FROM t1 ORDER BY STRCMP(STDDEV_SAMP(a), 'bar')", length=61, parser_state=0x7f0c4a9d05e0) at /data/src/10.1/sql/sql_parse.cc:7468
#22 0x00005619723f0ec4 in dispatch_command (command=COM_QUERY, thd=0x7f0c418d5070, packet=0x7f0c443f9071 "", packet_length=61) at /data/src/10.1/sql/sql_parse.cc:1496
#23 0x00005619723efc3d in do_command (thd=0x7f0c418d5070) at /data/src/10.1/sql/sql_parse.cc:1124
#24 0x000056197252ad90 in do_handle_one_connection (thd_arg=0x7f0c418d5070) at /data/src/10.1/sql/sql_connect.cc:1330
#25 0x000056197252aaf4 in handle_one_connection (arg=0x7f0c418d5070) at /data/src/10.1/sql/sql_connect.cc:1242
#26 0x00005619728e95e8 in pfs_spawn_thread (arg=0x7f0c48039ef0) at /data/src/10.1/storage/perfschema/pfs.cc:1861
#27 0x00007f0c4a651494 in start_thread (arg=0x7f0c4a9d1b00) at pthread_create.c:333
#28 0x00007f0c48a0a93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Couldn't reproduce on 10.2+.
No obvious effect on non-debug builds.



 Comments   
Comment by Alexander Barkov [ 2019-08-16 ]

10.1 vs 10.3 go through different execution patch.

JOIN::test_if_need_tmp_table() returns true in 10.1
JOIN::test_if_need_tmp_table() returns false in 10.2
JOIN::test_if_need_tmp_table() returns false in 10.3

Item::create_tmp_field() erroneously creates a Field_long for Item_func_set_user_var, although its data type is MYSQL_TYPE_LONGLONG.

This seems to have been fixed in 10.3.1 by:

commit e5145a5ac3e52b697b095c5338f7244c7e7a5119
Author: Alexander Barkov <bar@mariadb.org>  2017-05-24 15:43:09
 
    MDEV-12546 Wrong metadata or data type for string user variables

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