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
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. /bugs.launchpad .net/bugs/ 607449 size=67108864 size=2097152 connections= 14 size)*max_ threads = mysqld( my_print_ stacktrace+ 0x35)[0x87acc5] mysqld( handle_ segfault+ 0x31d)[ 0x5b6fbd] libpthread. so.0[0x3fc700e4 c0] mysqld( _ZN7handler25up date_global_ table_statsEv+ 0x172)[ 0x69b322] mysqld( _Z15close_ temporaryP8st_ tablebb+ 0x40)[0x6055f0] mysqld( _ZN14Relay_ log_info22close _temporary_ tablesEv+ 0x26)[0x6e7666] mysqld( _Z15end_ master_ infoP11Master_ info+0x2c) [0x6e91fc] mysqld( _Z15close_ active_ miv+0x1f) [0x6db85f] mysqld( kill_server_ thread+ 0x338)[ 0x5b9a28] libpthread. so.0[0x3fc70063 67] libc.so. 6(clone+ 0x6d)[0x3fc60d3 09d] /bugs.launchpad .net/percona- server/ +bug/607449/ +subscribe
> I can't reproduce this bug.
>
> --
> Crash on shutdown with userstat_running=1
> https:/
> 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_
> read_buffer_
> max_used_
> max_threads=500
> threads_connected=0
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_
> 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/
> /usr/sbin/
> /lib64/
> /usr/sbin/
> /usr/sbin/
>
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
> /lib64/
> /lib64/
>
> This is slave with userstat_running=1
>
> To unsubscribe from this bug, go to:
> https:/
>
--
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 www.percona. com/training/
http://