[MDEV-16514]  mysqld got signal 11 Created: 2018-06-18  Updated: 2018-07-17  Resolved: 2018-07-17

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 5.5.52-galera
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Joseph Oreste (Inactive) Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

Centos6.8


 Description   

We have not been able to determine the cause of the signal 11. Reviewing database and server log files available the mysql error log shows a backtrace which I will submit below. Looking for feedback on how to detect the cause of the signal 11 and subsequent dump of the database.

Thread pointer: 0x0x7f2b85a94000
 
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 = 0x7f29b753ed10 thread_stack 0x48000
 
/usr/sbin/mysqld(my_print_stacktrace+0x2b)[0xa9edfb]
 
/usr/sbin/mysqld(handle_fatal_signal+0x398)[0x6f0578]
 
/lib64/libpthread.so.0[0x3c27a0f7e0]
 
/lib64/libc.so.6[0x3c2773394f]
 
/usr/sbin/mysqld(_ZN6String6appendEPKc+0x2a)[0x61521a]
 
/usr/sbin/mysqld(thd_security_context+0x171)[0x57a721]
 
/usr/sbin/mysqld[0x82fc15]
 
/usr/sbin/mysqld[0x934712]
 
/usr/sbin/mysqld[0x87069e]
 
/usr/sbin/mysqld[0x831504]
 
/usr/sbin/mysqld(_Z14ha_show_statusP3THDP10handlerton12ha_stat_type+0x35a)[0x6f7d2a]
 
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4f91)[0x5acf51]
 
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x17f)[0x5af6bf]
 
/usr/sbin/mysqld[0x5af7b2]
 
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1929)[0x5b16b9]
 
/usr/sbin/mysqld(_Z10do_commandP3THD+0x20a)[0x5b1f0a]
 
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x30b)[0x66461b]
 
/usr/sbin/mysqld(handle_one_connection+0x4c)[0x6646ac]
 
/lib64/libpthread.so.0[0x3c27a07aa1]
 
/lib64/libc.so.6(clone+0x6d)[0x3c276e8bcd]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f2a3d3ee018): is an invalid pointer
 
Connection ID (thread ID): 1176023371
 
Status: NOT_KILLED



 Comments   
Comment by Elena Stepanova [ 2018-06-18 ]

There are two ways to approach it, using both at once would be most promising.
1) Enable the core dump if it's not enabled yet, and next time the crash happens, get full all threads' stack trace from it. Even though you are running a non-debug version, I think CentOS binaries are not stripped, so the stack trace can be marginally useful.
2) Enable the general log (also sometimes known as query log), if not enabled yet. Even though the crash report doesn't show the actual query which causes the crash, it shows the connection ID where it happened. When it crashes, the last query from this connection in the general log will be the one that causes the problem.

Comment by Joseph Oreste (Inactive) [ 2018-07-17 ]

To date we are unable to reproduce the error. I think we can close this ticket.

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