Debug assertion with incorrect utility user specification

[Alexey Kopytov]

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

[George Ormond Lorch III (gl-az)]

Weird. In 5.5 this did behave as you described it should. The idea was
that if everything wasn't perfect (valid user name, password, etc) the
server would just fail to start with an error from acl_init. I will look
into this and see if a simple fix and a catching test case can be done
and included in the new privileges functionality. Just looking at the
stacktrace though, it _looks_ like maybe 5.6 can't handle an init error
happening where it does, like maybe it is trying to clean up something
that hasn't been initialized yet, but that is just a guess...

On 8/26/2013 11:44 PM, Launchpad Bug Tracker wrote:
> Alexey Kopytov (akopytov) has assigned this bug to you for 5.6:
>
> 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
>
> ** Affects: percona-server
> Importance: Undecided
> Status: New
>
> ** Affects: percona-server/5.1
> Importance: Undecided
> Status: Invalid
>
> ** Affects: percona-server/5.5
> Importance: Low
> Assignee: George Ormond Lorch III (gl-az)
> Status: Triaged
>
> ** Affects: percona-server/5.6
> Importance: Undecided
> Status: New
>

--
George O. Lorch III
Software Engineer, Percona
[phone] x542 US/Arizona (GMT -7)
skype: george.ormond.lorch.iii

[Alexey Kopytov (akopytov)]

George,

that was on 5.5.

[George Ormond Lorch III (gl-az)]

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.

[Alexey Kopytov (akopytov)]

George,

Can you report it upstream?

[Alexey Kopytov (akopytov)]

Bug #1221590 is a duplicate of this one.

[George Ormond Lorch III (gl-az)]

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

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2040