[MDEV-22709] Assertion `store.length() <= (256L*256L*256L-1)' failed in net_send_ok Created: 2020-05-26  Updated: 2021-07-05  Resolved: 2021-07-05

Status: Closed
Project: MariaDB Server
Component/s: Variables
Affects Version/s: 10.5.4
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: not-10.1, not-10.2, not-10.3, not-10.4, regression

Issue Links:
PartOf
is part of MDEV-16470 Session user variables tracker Stalled
Problem/Incident
is caused by MDEV-16470 Session user variables tracker Stalled

 Description   

SET SESSION session_track_user_variables=1;
SET @inserted_value=REPEAT(1,16777180);  # Only crashes when >=16777180 (max = 16777216)

Leads to:

10.5.4 8569dac1ec9f6853a0b2f3ea9bcbda67644ead24

mysqld: /test/10.5_dbg/sql/protocol.cc:285: bool net_send_ok(THD*, uint, uint, ulonglong, ulonglong, const char*, bool, bool): Assertion `store.length() <= (256L*256L*256L-1)' failed.

10.5.4 8569dac1ec9f6853a0b2f3ea9bcbda67644ead24

Core was generated by `/test/MD260520-mariadb-10.5.4-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6)
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
[Current thread is 1 (Thread 0x148e2cc38700 (LWP 3878224))]
(gdb) bt
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
#1  0x0000565006e45d7a in my_write_core (sig=sig@entry=6) at /test/10.5_dbg/mysys/stacktrace.c:518
#2  0x00005650065eb385 in handle_fatal_signal (sig=6) at /test/10.5_dbg/sql/signal_handler.cc:330
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5  0x0000148e2b37c801 in __GI_abort () at abort.c:79
#6  0x0000148e2b36c39a in __assert_fail_base (fmt=0x148e2b4f37d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x565006f9ca50 "store.length() <= (256L*256L*256L-1)", file=file@entry=0x565006f9c540 "/test/10.5_dbg/sql/protocol.cc", line=line@entry=285, function=function@entry=0x565006f9d820 <net_send_ok(THD*, unsigned int, unsigned int, unsigned long long, unsigned long long, char const*, bool, bool)::__PRETTY_FUNCTION__> "bool net_send_ok(THD*, uint, uint, ulonglong, ulonglong, const char*, bool, bool)") at assert.c:92
#7  0x0000148e2b36c412 in __GI___assert_fail (assertion=assertion@entry=0x565006f9ca50 "store.length() <= (256L*256L*256L-1)", file=file@entry=0x565006f9c540 "/test/10.5_dbg/sql/protocol.cc", line=line@entry=285, function=function@entry=0x565006f9d820 <net_send_ok(THD*, unsigned int, unsigned int, unsigned long long, unsigned long long, char const*, bool, bool)::__PRETTY_FUNCTION__> "bool net_send_ok(THD*, uint, uint, ulonglong, ulonglong, const char*, bool, bool)") at assert.c:101
#8  0x000056500624f222 in net_send_ok (thd=0x148e0a015088, server_status=server_status@entry=16386, statement_warn_count=statement_warn_count@entry=0, affected_rows=affected_rows@entry=0, id=id@entry=0, message=<optimized out>, message@entry=0x148e0a01abab "", is_eof=false, skip_flush=false) at /test/10.5_dbg/sql/protocol.cc:285
#9  0x000056500624f3fa in Protocol::send_ok (this=0x148e0a015650, server_status=16386, statement_warn_count=0, affected_rows=0, last_insert_id=0, message=0x148e0a01abab "", skip_flush=false) at /test/10.5_dbg/sql/protocol.cc:643
#10 0x000056500624fd52 in Protocol::end_statement (this=0x148e0a015650) at /test/10.5_dbg/sql/protocol.cc:606
#11 0x000056500633cbc1 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x148e0a015088, packet=<optimized out>, packet@entry=0x148e0a067089 "SET @inserted_value=REPEAT(1,16777180)", packet_length=<optimized out>, packet_length@entry=38, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:2467
#12 0x000056500633931c in do_command (thd=0x148e0a015088) at /test/10.5_dbg/sql/sql_parse.cc:1355
#13 0x000056500649373f in do_handle_one_connection (connect=<optimized out>, connect@entry=0x148e0b8453a8, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1411
#14 0x0000565006493e5b in handle_one_connection (arg=arg@entry=0x148e0b8453a8) at /test/10.5_dbg/sql/sql_connect.cc:1313
#15 0x00005650068f314e in pfs_spawn_thread (arg=0x148e2a845888) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201
#16 0x0000148e2c05f6db in start_thread (arg=0x148e2cc38700) at pthread_create.c:463
#17 0x0000148e2b45d88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.5.4 (dbg)

Bug confirmed not present in:
MariaDB: 10.1.46 (dbg), 10.1.46 (opt), 10.2.33 (dbg), 10.2.33 (opt), 10.3.24 (dbg), 10.3.24 (opt), 10.4.14 (dbg), 10.4.14 (opt), 10.5.4 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)



 Comments   
Comment by Oleksandr Byelkin [ 2020-06-11 ]

We are trying to send more then allowed packet.

Comment by Oleksandr Byelkin [ 2020-06-11 ]

and it is exactly what that "implementor" have not copied from session traking probably because just did not understand what is checked.

Comment by Oleksandr Byelkin [ 2020-06-12 ]

user variable tracking removed from 10.5

Comment by Oleksandr Byelkin [ 2020-06-12 ]

shoud be rechecked after implementing MDEV-16470

Comment by Oleksandr Byelkin [ 2020-12-10 ]

julien.fritsch it is really critical bug of removed feature (code is present but commented out) MDEV-16470

Comment by Roel Van de Paar [ 2021-03-10 ]

In 10.6 the feature is not enabled yet, and so 10.6 is not affected:

10.6.0>SET SESSION session_track_user_variables=1;
ERROR 1193 (HY000): Unknown system variable 'session_track_user_variables'

Comment by Sergei Golubchik [ 2021-07-05 ]

The bug isn't present in any of the recent releases

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