Crash on shutdown with userstat_running=1

[Peter Zaitsev]

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

[Oleg Tsarev (tsarev)]

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

[Peter Zaitsev (pz-percona)]

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: [phone] ext 501 Skype: peter_zaitsev
24/7 Emergency Line [phone] ext 911

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

[Oleg Tsarev (tsarev)]

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.

[Yasufumi Kinoshita (yasufumi-kinoshita)]

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.

[Shahriyar Rzayev (rzayev-sehriyar)]

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