[MDEV-27182] mysql 5.7.22 is crash and restart with mariadb server_audit Created: 2021-12-07  Updated: 2023-12-14  Resolved: 2023-12-14

Status: Closed
Project: MariaDB Server
Component/s: Plugin - Audit
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: czxin788 Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: crash
Environment:

mysql 5.7.22



 Description   

2021-12-07 09:21:37  - 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=536870912
read_buffer_size=33554432
max_used_connections=1248
max_threads=5000
thread_count=352
connection_count=351
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 246351163 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation
 
Thread pointer: 0x7f50cd8802f0
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 = 7f52e4544e68 thread_stack 0x40000
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0xf4b6d5]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x4a4)[0x7d0d74]
/lib64/libpthread.so.0(+0xf5d0)[0x7f59661f55d0]
/lib64/libc.so.6(+0x1558fe)[0x7f5964cfe8fe]
/usr/local/mysql/lib/plugin/server_audit.so(auditing+0xb63)[0x7f52f40648c3]
/usr/local/mysql/lib/plugin/server_audit.so(+0x94fb)[0x7f52f40654fb]
/usr/local/mysql/bin/mysqld[0x7d1e7f]
/usr/local/mysql/bin/mysqld(_Z18mysql_audit_notifyP3THD30mysql_event_general_subclass_tPKciS3_m+0x216)[0x7d2dd6]
/usr/local/mysql/bin/mysqld(_ZN12Query_logger17general_log_writeEP3THD19enum_server_commandPKcm+0x5f)[0xc60b9f]
/usr/local/mysql/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x1671)[0xd1c1a1]
/usr/local/mysql/bin/mysqld(_Z10do_commandP3THD+0x194)[0xd1cb74]
/usr/local/mysql/bin/mysqld(handle_connection+0x29c)[0xdedaec]
/usr/local/mysql/bin/mysqld(pfs_spawn_thread+0x174)[0x1256a94]
/lib64/libpthread.so.0(+0x7dd5)[0x7f59661eddd5]
/lib64/libc.so.6(clone+0x6d)[0x7f5964ca6ead]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): is an invalid pointer
Connection ID (thread ID): 68329
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.
2021-12-07T09:21:41.723568+08:00 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2021-12-07T09:21:41.723666+08:00 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in 
a future release.
2021-12-07T09:21:41.723719+08:00 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled
2021-12-07T09:21:41.723756+08:00 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.7.22-log) starting as process 4205 ...
2021-12-07T09:21:41.769970+08:00 0 [Note] InnoDB: PUNCH HOLE support available
2021-12-07T09:21:41.770029+08:00 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-12-07T09:21:41.770035+08:00 0 [Note] InnoDB: Uses event mutexes
2021-12-07T09:21:41.770040+08:00 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier

I don't know the reason,and how can I do to slove it?



 Comments   
Comment by Marko Mäkelä [ 2023-12-14 ]

This looks like MySQL, not MariaDB Server, so this is not our bug. The __sync_synchronize() that occurs in the log output was removed from MariaDB Server 10.2.3 in MDEV-10813.

Generated at Thu Feb 08 09:50:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.