[MDEV-22702] Assertion `!field->is_null()' failed in my_decimal::my_decimal Created: 2020-05-25  Updated: 2023-11-28

Status: Stalled
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 11.0, 11.1, 11.2, 11.3
Fix Version/s: 10.4, 10.5, 10.6, 10.11, 11.0, 11.1, 11.2, 11.3

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-22700 Assertion `subq_pred->engine->engine_... Stalled
relates to MDEV-23438 Assertion `!field->is_null()' failed ... Stalled
relates to MDEV-23749 Assertion `!field->is_null()' failed ... Stalled

 Description   

Reproducible on 10.4-10.5, with MyIsam, not with InnoDB, with empty table t1.

create table t1 (a1 int, a2 decimal(10,0) not null) engine=myisam;
select min(1 mod a1), bit_or(a2) over () from t1;

10.4 ea7830eef48333e28f98a9

#3  <signal handler called>
#4  0x00007f75bc066428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#5  0x00007f75bc06802a in __GI_abort () at abort.c:89
#6  0x00007f75bc05ebd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55b47e2f8ab5 "!field->is_null()", file=file@entry=0x55b47e2f8a38 "/10.4/sql/my_decimal.cc", line=line@entry=382, function=function@entry=0x55b47e2f8c10 <my_decimal::my_decimal(Field*)::__PRETTY_FUNCTION__> "my_decimal::my_decimal(Field*)") at assert.c:92
#7  0x00007f75bc05ec82 in __GI___assert_fail (assertion=0x55b47e2f8ab5 "!field->is_null()", file=0x55b47e2f8a38 "/10.4/sql/my_decimal.cc", line=382, function=0x55b47e2f8c10 <my_decimal::my_decimal(Field*)::__PRETTY_FUNCTION__> "my_decimal::my_decimal(Field*)") at assert.c:101
#8  0x000055b47d8df4f3 in my_decimal::my_decimal (this=0x7f75b45b90c0, field=0x7f756419eb30) at /10.4/sql/my_decimal.cc:382
#9  0x000055b47d756d82 in Field::do_field_decimal (copy=0x7f7564017870) at /10.4/sql/field_conv.cc:416
#10 0x000055b47d495b64 in copy_fields (param=0x7f75640177d0) at /10.4/sql/sql_select.cc:25029
#11 0x000055b47d48d65c in end_write (join=0x7f7564015170, join_tab=0x7f7564017428, end_of_records=false) at /10.4/sql/sql_select.cc:21786
#12 0x000055b47d4a0868 in AGGR_OP::put_record (this=0x7f7564017ac8, end_of_records=false) at /10.4/sql/sql_select.cc:28596
#13 0x000055b47d4a64f1 in AGGR_OP::put_record (this=0x7f7564017ac8) at /10.4/sql/sql_select.h:1046
#14 0x000055b47d48954a in sub_select_postjoin_aggr (join=0x7f7564015170, join_tab=0x7f7564017428, end_of_records=false) at /10.4/sql/sql_select.cc:20086
#15 0x000055b47d488f38 in do_select (join=0x7f7564015170, procedure=0x0) at /10.4/sql/sql_select.cc:19904
#16 0x000055b47d45dbf9 in JOIN::exec_inner (this=0x7f7564015170) at /10.4/sql/sql_select.cc:4459
#17 0x000055b47d45cd36 in JOIN::exec (this=0x7f7564015170) at /10.4/sql/sql_select.cc:4241
#18 0x000055b47d45e44b in mysql_select (thd=0x7f7564000af0, tables=0x7f7564014108, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f7564015148, unit=0x7f7564004a18, select_lex=0x7f7564013260) at /10.4/sql/sql_select.cc:4673
#19 0x000055b47d44dee4 in handle_select (thd=0x7f7564000af0, lex=0x7f7564004958, result=0x7f7564015148, setup_tables_done_option=0) at /10.4/sql/sql_select.cc:422
#20 0x000055b47d4147ac in execute_sqlcom_select (thd=0x7f7564000af0, all_tables=0x7f7564014108) at /10.4/sql/sql_parse.cc:6359
#21 0x000055b47d40ae98 in mysql_execute_command (thd=0x7f7564000af0) at /10.4/sql/sql_parse.cc:3898
#22 0x000055b47d41878d in mysql_parse (thd=0x7f7564000af0, rawbuf=0x7f7564013198 "select min(1 mod a1), bit_or(a2) over () from t1", length=48, parser_state=0x7f75b45ba3f0, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:7900
#23 0x000055b47d404d2d in dispatch_command (command=COM_QUERY, thd=0x7f7564000af0, packet=0x7f75641372a1 "", packet_length=48, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:1842
#24 0x000055b47d4034a3 in do_command (thd=0x7f7564000af0) at /10.4/sql/sql_parse.cc:1360
#25 0x000055b47d58c3fe in do_handle_one_connection (connect=0x55b48080e9d0) at /10.4/sql/sql_connect.cc:1412
#26 0x000055b47d58c127 in handle_one_connection (arg=0x55b48080e9d0) at /10.4/sql/sql_connect.cc:1316
#27 0x000055b47df8d87d in pfs_spawn_thread (arg=0x55b48077dc80) at /10.4/storage/perfschema/pfs.cc:1869
#28 0x00007f75bd5556ba in start_thread (arg=0x7f75b45bb700) at pthread_create.c:333
#29 0x00007f75bc13841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

No visible effect on non-debug build



 Comments   
Comment by Varun Gupta (Inactive) [ 2020-07-01 ]

The assert is hit here because we have a degenerate join here but we need to eveluate the window function. The values passed to the window function is NULL for column a2 though it is defined as NOT NULL. The function expect
the values to always be NOT NULL.

Here is the code snippet

my_decimal::my_decimal(Field *field)
{
  init();
  DBUG_ASSERT(!field->is_null());
#ifdef DBUG_ASSERT_EXISTS
  my_decimal *dec=
#endif
  field->val_decimal(this);
  DBUG_ASSERT(dec == this);
}

Comment by Varun Gupta (Inactive) [ 2020-07-08 ]

So adding a field in the select list for the query in the description

MariaDB [test]> CREATE TABLE t1(a INT, b DECIMAL(10, 0) NOT NULL);
Query OK, 0 rows affected (0.003 sec)
 
MariaDB [test]> SELECT a, min(a), bit_or(b) OVER () FROM t1;
+------+--------+-------------------+
| a    | min(a) | bit_or(b) OVER () |
+------+--------+-------------------+
| NULL |   NULL |                 0 |
+------+--------+-------------------+
1 row in set (0.007 sec)

The above query works.
But when i run

SELECT min(a), bit_or(b) OVER () FROM t1;

This query hits the ASSERT

Comment by Varun Gupta (Inactive) [ 2020-07-08 ]

Patch
http://lists.askmonty.org/pipermail/commits/2020-July/014281.html

Comment by Sergei Petrunia [ 2020-08-06 ]

Review: https://lists.launchpad.net/maria-developers/msg12347.html

Comment by Sergei Petrunia [ 2020-12-22 ]

Review was provided long ago? See the comment above

Comment by Varun Gupta (Inactive) [ 2020-12-24 ]

The patch is in 10.2-varun

Comment by Varun Gupta (Inactive) [ 2021-01-20 ]

Patch
https://github.com/MariaDB/server/commit/c6686d2cd65dc31b9ec56ef695e8d2f4dc34e48f

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