Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

LP #1217213: Debug assertion with incorrect utility user specification

Description

**Reported in Launchpad by Alexey Kopytov last update 12-09-2013 10:16:29

I was testing utility user functionality as a part of the --utility-user-privilege review, and provided an incorrect utility user specification by mistake: --utility-user=foo. The server is supposed to abort with an error in this case, but I got a debug assertion failure:

130827 10:40:55 Percona XtraDB (http://www.percona.com) 5.5.32-29.3 started; log sequence number 1597945
130827 10:40:55 [ERROR] 'utility user' specified as 'foo' is anonymous and not allowed.
Assertion failed: (!table->file || table->file->inited == handler::NONE), function close_thread_table, file /Users/kaa/src/launchpad/percona-server/BT23597_utility-user-access_5.5/Percona-Server/sql/sql_base.cc, line 1577.

Program received signal SIGABRT, Aborted.
0x00007fff85625212 in __pthread_kill ()
(gdb) bt
#0 0x00007fff85625212 in __pthread_kill ()
#1 0x00007fff87edcb54 in pthread_kill ()
#2 0x00007fff87f20dce in abort ()
#3 0x00007fff87f21e2a in __assert_rtn ()
#4 0x0000000100249897 in close_thread_table (thd=0x10f800000, table_ptr=0x10f8000a0) at sql_base.cc:1577
#5 0x000000010024a06b in close_open_tables (thd=0x10f800000) at sql_base.cc:1356
#6 0x000000010024a482 in close_thread_tables (thd=0x10f800000) at sql_base.cc:1563
#7 0x000000010024a522 in close_mysql_tables (thd=0x10f800000) at sql_base.cc:9903
#8 0x000000010022bcfc in acl_reload (thd=0x10f800000) at sql_acl.cc:1197
#9 0x000000010022bf38 in acl_init (dont_read_acl_tables=false) at sql_acl.cc:651
#10 0x000000010018e8ec in mysqld_main (argc=4, argv=0x10130a5e0) at mysqld.cc:4710
#11 0x0000000100002730 in main (argc=4, argv=0x7fff5fbff978) at main.cc:25

Environment

None

Activity

Julia Vural 
March 4, 2025 at 9:22 PM

It appears that this issue is no longer being worked on, so we are closing it for housekeeping purposes. If you believe the issue still exists, please open a new ticket after confirming it's present in the latest release.

lpjirasync 
January 22, 2018 at 6:40 PM

**Comment from Launchpad by: George Ormond Lorch III on: 11-09-2013 19:35:24

Reported upstream: http://bugs.mysql.com/bug.php?id=70304

lpjirasync 
January 22, 2018 at 6:40 PM

**Comment from Launchpad by: Alexey Kopytov on: 07-09-2013 05:43:46

Bug #1221590 is a duplicate of this one.

lpjirasync 
January 22, 2018 at 6:40 PM

**Comment from Launchpad by: Alexey Kopytov on: 28-08-2013 05:35:15

George,

Can you report it upstream?

lpjirasync 
January 22, 2018 at 6:40 PM

**Comment from Launchpad by: George Ormond Lorch III on: 27-08-2013 20:00:25

OK, this is an upstream issue that is only now more visible because the utility user functionality create a path that may be hit more often via user error. That path is basically any false exit from sql/sql_acl.cc:acl_load after init_read_record has been called.

I injected:
return_val= FALSE;
goto end:
in several placed along acl_reload and everything operated normally until I reached init_read_record, once I return with an error after that, the server will always assert in the same way. I verified this on MySQL 5.5.33 debug.

Won't Do

Details

Assignee

Reporter

Labels

Priority

Created January 22, 2018 at 6:39 PM
Updated March 4, 2025 at 9:22 PM
Resolved March 4, 2025 at 9:22 PM