|
The test case from the description doesn't cause a crash anymore (the statement fails with ER_PLUGIN_IS_NOT_LOADED), but this one does:
If you do it via MTR, run with --mysqld=--unix-socket
CREATE USER foo;
|
GRANT EXECUTE ON * TO foo IDENTIFIED WITH unix_socket AS PASSWORD('bar');
|
|
# Cleanup
|
DROP USER foo;
|
|
10.4 0bc42602
|
mysqld: /data/src/10.4/sql/protocol.cc:606: void Protocol::end_statement(): Assertion `0' failed.
|
190327 16:09:08 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007efe5474aee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#8 0x0000562757d9d4af in Protocol::end_statement (this=0x7efe3c0010c8) at /data/src/10.4/sql/protocol.cc:606
|
#9 0x0000562757eba9ce in dispatch_command (command=COM_QUERY, thd=0x7efe3c000b00, packet=0x7efe3c139311 "GRANT EXECUTE ON * TO foo IDENTIFIED WITH unix_socket AS PASSWORD('bar')", packet_length=72, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:2427
|
#10 0x0000562757eb72b8 in do_command (thd=0x7efe3c000b00) at /data/src/10.4/sql/sql_parse.cc:1365
|
#11 0x00005627580310d5 in do_handle_one_connection (connect=0x56275af6e210) at /data/src/10.4/sql/sql_connect.cc:1398
|
#12 0x0000562758030e46 in handle_one_connection (arg=0x56275af6e210) at /data/src/10.4/sql/sql_connect.cc:1301
|
#13 0x00005627585269dd in pfs_spawn_thread (arg=0x56275aff4090) at /data/src/10.4/storage/perfschema/pfs.cc:1862
|
#14 0x00007efe56639494 in start_thread (arg=0x7efe4e8c5700) at pthread_create.c:333
|
#15 0x00007efe5480793f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
|
|
Can't repeat. Running test with -mysqld=-unix-socket also fails with error ER_PLUGIN_IS_NOT_LOADED and doesn't give assertion
|
|
The second test case still fails for me on all 10.4+.
rucha174, are you sure you copied the test case itself rather than just added a command line option? The test case in the comment is different from the original one. With a good build it shouldn't fail (not with ER_PLUGIN_IS_NOT_LOADED at least), because it uses unix_socket plugin and you force loading it from the command line.
In retrospect, maybe it was a different bug and I should have filed it separately, but all protocol assertion zero failures look alike, so these two were considered related just due to belonging to the authentication universe.
|
|
elenst Okay, I checked I was running the test in description with -mysqld=-unix-socket. Now I ran the test given in the comment on 10.5. You're right, it still fails on 10.4+. Doesn't fail on 10.4 though. I'll change the affected version and fix version. Thanks!
|
|
No, by 10.4+ I mean 10.4 and higher. It does fail for me on the top of current 10.4, see below (I've added revision output directly to the test, to avoid any doubts).
If it doesn't fail for you, is it possible that you have changes in your local tree which are not in the main 10.4 branch yet which have fixed it?
|
10.4 12cad0c34
|
show variables like '%revision%';
|
Variable_name Value
|
version_source_revision 12cad0c3468d734e041d4ef0cd5a26d2a28606fc
|
CREATE USER foo;
|
GRANT EXECUTE ON * TO foo IDENTIFIED WITH unix_socket AS PASSWORD('bar');
|
bug.t [ fail ]
|
Test ended at 2022-01-28 00:33:56
|
|
CURRENT_TEST: bug.t
|
mysqltest: At line 4: query 'GRANT EXECUTE ON * TO foo IDENTIFIED WITH unix_socket AS PASSWORD('bar')' failed: 2013: Lost connection to MySQL server during query
|
...
|
#7 0x00007fc32c6a9662 in __GI___assert_fail (assertion=0x564ffb080770 "0", file=0x564ffb080380 "/data/src/10.4-bug/sql/protocol.cc", line=615, function=0x564ffb0806e8 "void Protocol::end_statement()") at assert.c:101
|
#8 0x0000564ffa293edf in Protocol::end_statement (this=0x7fc314001368) at /data/src/10.4-bug/sql/protocol.cc:615
|
#9 0x0000564ffa3bbb4a in dispatch_command (command=COM_QUERY, thd=0x7fc314000d90, packet=0x7fc31400abf1 "GRANT EXECUTE ON * TO foo IDENTIFIED WITH unix_socket AS PASSWORD('bar')", packet_length=72, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:2441
|
#10 0x0000564ffa3b83c6 in do_command (thd=0x7fc314000d90) at /data/src/10.4-bug/sql/sql_parse.cc:1373
|
#11 0x0000564ffa54652f in do_handle_one_connection (connect=0x564ffda41f10) at /data/src/10.4-bug/sql/sql_connect.cc:1420
|
#12 0x0000564ffa5461d7 in handle_one_connection (arg=0x564ffda41f10) at /data/src/10.4-bug/sql/sql_connect.cc:1316
|
#13 0x0000564ffaa61989 in pfs_spawn_thread (arg=0x564ffda89220) at /data/src/10.4-bug/storage/perfschema/pfs.cc:1869
|
#14 0x00007fc32cb75ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#15 0x00007fc32c772def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
|
|
elenst , right, sorry. I can repeat it on 10.4. Don't know what happened earlier. Thanks !
|