Percona Server with XtraDB

Crash on shutdown with userstat_running=1

Reported by Peter Zaitsev on 2010-07-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Critical
Unassigned

Bug Description

XtraDB 10.2 crashes with this stack trace

100719 15:33:54 [Note] Error reading relay log event: slave SQL thread was killed
100719 15:33:54 - 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.

key_buffer_size=67108864
read_buffer_size=2097152
max_used_connections=14
max_threads=500
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2118864 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 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 = (nil) thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x87acc5]
/usr/sbin/mysqld(handle_segfault+0x31d)[0x5b6fbd]
/lib64/libpthread.so.0[0x3fc700e4c0]
/usr/sbin/mysqld(_ZN7handler25update_global_table_statsEv+0x172)[0x69b322]
/usr/sbin/mysqld(_Z15close_temporaryP8st_tablebb+0x40)[0x6055f0]
/usr/sbin/mysqld(_ZN14Relay_log_info22close_temporary_tablesEv+0x26)[0x6e7666]
/usr/sbin/mysqld(_Z15end_master_infoP11Master_info+0x2c)[0x6e91fc]
/usr/sbin/mysqld(_Z15close_active_miv+0x1f)[0x6db85f]
/usr/sbin/mysqld(kill_server_thread+0x338)[0x5b9a28]
/lib64/libpthread.so.0[0x3fc7006367]
/lib64/libc.so.6(clone+0x6d)[0x3fc60d309d]

This is slave with userstat_running=1

Changed in percona-server:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Oleg Tsarev (tsarev)
milestone: none → 5.1-12.0
importance: High → Critical
Oleg Tsarev (tsarev) on 2010-07-20
Changed in percona-server:
status: Triaged → In Progress
Oleg Tsarev (tsarev) wrote :

Need test case for reproduce.
I can't reproduce this bug.

Oleg,

A lot of bugs are not reproducable and If I get the crash on customers
system often it hard to experiment
Can you use the stack trace to identify the code location where crash
happened ?

This is RPM for RHEL 5.0 64bit

On Tue, Jul 20, 2010 at 2:03 PM, Oleg Tsarev <email address hidden> wrote:

> Need test case for reproduce.
> I can't reproduce this bug.
>
> --
> Crash on shutdown with userstat_running=1
> https://bugs.launchpad.net/bugs/607449
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Percona Server with XtraDB: In Progress
>
> Bug description:
> XtraDB 10.2 crashes with this stack trace
>
>
> 100719 15:33:54 [Note] Error reading relay log event: slave SQL thread was
> killed
> 100719 15:33:54 - 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.
>
> key_buffer_size=67108864
> read_buffer_size=2097152
> max_used_connections=14
> max_threads=500
> threads_connected=0
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 2118864 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd: 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 = (nil) thread_stack 0x40000
> /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x87acc5]
> /usr/sbin/mysqld(handle_segfault+0x31d)[0x5b6fbd]
> /lib64/libpthread.so.0[0x3fc700e4c0]
> /usr/sbin/mysqld(_ZN7handler25update_global_table_statsEv+0x172)[0x69b322]
> /usr/sbin/mysqld(_Z15close_temporaryP8st_tablebb+0x40)[0x6055f0]
>
> /usr/sbin/mysqld(_ZN14Relay_log_info22close_temporary_tablesEv+0x26)[0x6e7666]
> /usr/sbin/mysqld(_Z15end_master_infoP11Master_info+0x2c)[0x6e91fc]
> /usr/sbin/mysqld(_Z15close_active_miv+0x1f)[0x6db85f]
> /usr/sbin/mysqld(kill_server_thread+0x338)[0x5b9a28]
> /lib64/libpthread.so.0[0x3fc7006367]
> /lib64/libc.so.6(clone+0x6d)[0x3fc60d309d]
>
> This is slave with userstat_running=1
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/percona-server/+bug/607449/+subscribe
>

--
Peter Zaitsev, CEO, Percona Inc.
Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev
24/7 Emergency Line +1 888 401 3401 ext 911

Percona Training Workshops
http://www.percona.com/training/

Oleg Tsarev (tsarev) wrote :

Peter,

i look around th segfault, but don't found bad in first (i hoped reproduce bug first).
Ok, i carry review all neighbour code.

I found 1 problem at handler::update_global_table_stats().
current_thd is not proper in the path of the stacktrace.
I will fix it.

Changed in percona-server:
assignee: Oleg Tsarev (tsarev) → Yasufumi Kinoshita (yasufumi-kinoshita)
Changed in percona-server:
status: In Progress → Fix Committed
Changed in percona-server:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers