SIGHUP at startup crashes the server

Bug #1249193 reported by Raghavendra D Prabhu
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
MySQL patches by Codership
Invalid
Undecided
Unassigned
5.5
Fix Released
High
Teemu Ollakka
Percona Server moved to https://jira.percona.com/projects/PS
Invalid
Undecided
Unassigned
5.1
Invalid
Undecided
Unassigned
5.5
Fix Released
High
Sergei Glushchenko
5.6
Invalid
Undecided
Unassigned

Bug Description

Repeatable easily with (for Percona Server 5.5)

=======================================================================

Session 1: (to ensure SIGHUP is sent at startup)

[root@Archie percona-xtradb-cluster]# while true;do pkill -HUP mysqld; done

Session 2:

>>sudo mysqld --user=mysql
131108 10:42:20 InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
131108 10:42:20 InnoDB: The InnoDB memory heap is disabled
131108 10:42:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131108 10:42:20 InnoDB: Compressed tables use zlib 1.2.8
131108 10:42:20 InnoDB: Using Linux native AIO
131108 10:42:20 InnoDB: Initializing buffer pool, size = 128.0M
131108 10:42:20 InnoDB: Completed initialization of buffer pool
131108 10:42:20 InnoDB: highest supported file format is Barracuda.
131108 10:42:20 InnoDB: Waiting for the background threads to start
131108 10:42:21 Percona XtraDB (http://www.percona.com) 5.5.34-rel32.0 started; log sequence number 1597945

Status information:

Current dir: /var/lib/mysql/
Running threads: 0 Stack size: 262144
Current locks:
lock: 0x117bd20:

lock: 0x117c260:

lock: 0x117c320:

lock: 0x117c3e0:

lock: 0x117bde0:

lock: 0x117bea0:

lock: 0x117bc60:

lock: 0x117bae0:

lock: 0x117bba0:

lock: 0x117c4a0:

lock: 0x117bf60:

lock: 0x117c1a0:

lock: 0x117c0e0:

lock: 0x117c020:

lock: 0x117b8a0:

lock: 0x117b960:

lock: 0x117ba20:

DB Table Version Thread Open Lock

Current refresh version: 1

Key caches:
default
Buffer_size: 16777216
Block_size: 1024
Division_limit: 100
Age_limit: 300
blocks used: 0
not flushed: 0
w_requests: 0
writes: 0
r_requests: 0
reads: 0

handler status:
read_key: 0
read_next: 0
read_rnd 0
read_first: 0
write: 0
delete 0
update: 0

Table status:
Opened tables: 1
Open tables: 0
Open files: 2
Open streams: 0

Alarm status:
Active alarms: 0
Max used alarms: 0
Next alarm time: 0

Memory status:
Non-mmapped space allocated from system: 10346496
Number of free chunks: 6
Number of fastbin blocks: 0
Number of mmapped regions: 16
Space in mmapped regions: 32931840
Maximum total allocated space: 0
Space available in freed fastbin blocks: 0
Total allocated space: 7909520
Total free space: 2436976
Top-most, releasable space: 2291568
Estimated memory (with thread stack): 43278336

Events status:
LLA = Last Locked At LUA = Last Unlocked At
WOC = Waiting On Condition DL = Data Locked

Event scheduler status:
05:12:21 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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=153
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 135774 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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 = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x7fb89a]
mysqld(handle_fatal_signal+0x30f)[0x6bcb0f]
/usr/lib/libpthread.so.0(+0xf870)[0x7f475efba870]
mysqld(_ZN15Event_scheduler20dump_internal_statusEv+0x40)[0x7d51f2]
mysqld(_ZN6Events20dump_internal_statusEv+0xdc)[0x63e02e]
mysqld(_Z18mysql_print_statusv+0x7af)[0x612f2b]
mysqld(signal_hand+0x5cd)[0x5142c7]
/usr/lib/libpthread.so.0(+0x80a2)[0x7f475efb30a2]
/usr/lib/libc.so.6(clone+0x6d)[0x7f475d81750d]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

================================================================================================

This is due to upstream http://bugs.mysql.com/bug.php?id=62311 but has been fixed only in 5.6.

Related branches

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

Tagging with pxc since it affects PXC too (for obvious reasons) and seems people are hitting it more there (may be some like to send SIGHUP at startup). Note, this is not due to mysqladmin debug (as some hypothesized in other forums) since this requires signal to be sent before the socket is open (so mysqladmin can't reach it before).

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Can not crash 5.6 or 5.1 this way, but easy to verify with 5.5:

...
Event scheduler status:
15:44:26 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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 342992 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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 = 0 thread_stack 0x40000
bin/mysqld(my_print_stacktrace+0x2e)[0x7bbb8e]
bin/mysqld(handle_fatal_signal+0x491)[0x6a0631]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0)[0x7f9ba335dbd0]
bin/mysqld(_ZN15Event_scheduler20dump_internal_statusEv+0x28)[0x795788]
bin/mysqld(_ZN6Events20dump_internal_statusEv+0xbb)[0x638e8b]
bin/mysqld(_Z18mysql_print_statusv+0x7cc)[0x61239c]
bin/mysqld(signal_hand+0x335)[0x530c65]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f8e)[0x7f9ba3355f8e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9ba2a77a0d]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Is this a Percona Server-specific bug or an upstream one?

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

It's an upstream bug (linked now), but there it was fixed only in 5.6.

tags: added: upstream
Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

Yes, it has been fixed only in 5.6 and closed, so I don't think it will be backported upstream.

Revision history for this message
Teemu Ollakka (teemu-ollakka) wrote :
tags: added: i42230
Changed in codership-mysql:
status: New → Invalid
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

The PS 5.5 fix has caused bug 1319904.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

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

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.