Valgrind error on main.audit_log_threadpool

Bug #1650322 reported by Laurynas Biveinis on 2016-12-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.5
Invalid
Undecided
Unassigned
5.6
Fix Released
High
Sergei Glushchenko
5.7
Invalid
High
Unassigned

Bug Description

On 5.6 trunk, Valgrind build:

$ ./mtr --debug-server --valgrind-mysqld audit_log_threadpool --valgrind-option=--track-origins=yes

==7496== Thread 21:
==7496== Conditional jump or move depends on uninitialised value(s)
==7496== at 0x77D715: mysql_rewrite_query(THD*) (sql_rewrite.cc:660)
==7496== by 0x664506: mysql_audit_general_log(THD*, char const*, unsigned int, char const*, unsigned long) (sql_audit.h:91)
==7496== by 0x66B07F: LOGGER::log_command(THD*, enum_server_command, char const*, unsigned long) (log.cc:2436)
==7496== by 0x66B193: general_log_print(THD*, enum_server_command, char const*, ...) (log.cc:2464)
==7496== by 0x6C2447: acl_authenticate(THD*, unsigned int) (sql_acl.cc:11502)
==7496== by 0x7069FA: check_connection(THD*) (sql_connect.cc:1219)
==7496== by 0x706BC4: login_connection(THD*) (sql_connect.cc:1289)
==7496== by 0x83A68C: threadpool_add_connection(THD*) (threadpool_common.cc:217)
==7496== by 0x83DDB7: handle_event(connection_t*) (threadpool_unix.cc:1559)
==7496== by 0x83E075: worker_main(void*) (threadpool_unix.cc:1617)
==7496== by 0xE5A984: pfs_spawn_thread (pfs.cc:1860)
==7496== by 0x58A06C9: start_thread (pthread_create.c:333)
==7496== by 0x64670AE: clone (clone.S:105)
==7496== Uninitialised value was created by a heap allocation
==7496== at 0x4C2CFCF: operator new(unsigned long) (vg_replace_malloc.c:332)
==7496== by 0x573CEC: handle_connections_sockets() (mysqld.cc:6861)
==7496== by 0x572844: mysqld_main(int, char**) (mysqld.cc:6111)
==7496== by 0x56592F: main (main.cc:25)
==7496==

Not sure if the culprit is audit, threadpool, or something else. Sergei, can you take a look?

tags: added: ci valgrind

It is thd->lex->contains_plaintext_password which is uninitialized. Usually it is set in lex_start. In this case we probably have not get to sql_parse yet. Lets see what is the difference with the thread-per-connection case.

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers