[MDEV-11191] server_audit from 10.0.28 crashes on MySQL 5.7 Created: 2016-10-31  Updated: 2017-01-10  Resolved: 2017-01-10

Status: Closed
Project: MariaDB Server
Component/s: Plugin - Audit
Affects Version/s: 10.0.28
Fix Version/s: 10.0.29

Type: Bug Priority: Major
Reporter: Owen Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: audit
Environment:

CentOS 7 and MySQL 5.7.16


Attachments: File my.cnf     File mysqld.log    
Issue Links:
Relates
relates to MDEV-10441 Document the server_audit_loc_info va... Closed
relates to MDEV-10905 PLUGIN_VAR_NOSYSVAR | PLUGIN_VAR_NOCM... Closed
Sprint: 10.0.29

 Description   

Using the server_audit.so plugin from 10.0.28 on MySQL 5.7.16 crashes MySQL.

The server_audit.so plugin from 10.0.27 worked without issue. I think this is related to MDEV-10441 and MDEV-10905. Those seem like the only changes to server_audit between 10.0.27 and 10.0.28.

https://github.com/MariaDB/server/commit/d61e5260fb9983ea8dff539b23a6d0a150c2065c#diff-d140eac18a0e7ddbe8192d10f3b422d1

2016-10-31T13:59:36.658206Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.16-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3307  MySQL Community Server (GPL)
13:59:54 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
 
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68190 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f66bc000ae0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f66f188ce70 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xef182b]
/usr/sbin/mysqld(handle_fatal_signal+0x461)[0x7ad8c1]
/lib64/libpthread.so.0(+0xf100)[0x7f67068a5100]
/usr/lib64/mysql/plugin/server_audit.so(auditing+0x67e)[0x7f66f18d78fe]
/usr/lib64/mysql/plugin/server_audit.so(+0x9b8b)[0x7f66f18d8b8b]
/usr/sbin/mysqld[0x7adac3]
/usr/sbin/mysqld(_Z18mysql_audit_notifyP3THD30mysql_event_general_subclass_tiPKcm+0x1f4)[0x7ae074]
/usr/sbin/mysqld(_ZN12Query_logger17general_log_printEP3THD19enum_server_commandPKcz+0xc5)[0xc112e5]
/usr/sbin/mysqld(_Z15acl_log_connectPKcS0_S0_S0_P3THD19enum_server_command+0xaf)[0x7b5fff]
/usr/sbin/mysqld(_Z16acl_authenticateP3THD19enum_server_command+0xb79)[0x7b6de9]
/usr/sbin/mysqld[0xc84dbd]
/usr/sbin/mysqld(_Z22thd_prepare_connectionP3THD+0x62)[0xc85f52]
/usr/sbin/mysqld(handle_connection+0x263)[0xd86993]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0x12645b4]
/lib64/libpthread.so.0(+0x7dc5)[0x7f670689ddc5]
/lib64/libc.so.6(clone+0x6d)[0x7f6705359ced]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 2
Status: NOT_KILLED
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.



 Comments   
Comment by Alexey Botchkov [ 2017-01-10 ]

Yep, this is the manifestation of the same problem. It's fixed in 5.5 already and the fix should get to the 10.0.

Generated at Thu Feb 08 07:48:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.