Percona Server with XtraDB

Crash with several adaptive hashes

Reported by Vadim Tkachenko on 2010-12-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
High
Unassigned

Bug Description

I am getting crash with --innodb_adaptive_hash_index_num=16

Stack traces:
http://percona.pastebin.com/ZjU4DjZ5

Changed in percona-server:
status: New → Confirmed
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → High
Vadim Tkachenko (vadim-tk) wrote :

log message

101210 23:18:34 Percona XtraDB (http://www.percona.com) 1.1.3-12.1 started; log sequence number 62258015514
101210 23:18:34 [Note] libexec/mysqld: ready for connections.
Version: '5.5.7-rc' socket: '/tmp/mysql.sock' port: 3306 Source distribution
101210 23:19:57 - 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=8388608
read_buffer_size=131072
max_used_connections=18
max_threads=3000
thread_count=18
connection_count=18
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6570973 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x7f65080bd9b0
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 = 0x413b3108 thread_stack 0x40000
libexec/mysqld(my_print_stacktrace+0x2e)[0x87218e]
libexec/mysqld(handle_segfault+0x341)[0x597e61]
/lib64/libpthread.so.0[0x300b40eb10]
libexec/mysqld[0x7db668]
libexec/mysqld[0x7c1642]
libexec/mysqld[0x783d83]
libexec/mysqld[0x78f758]
libexec/mysqld[0x77c181]
libexec/mysqld[0x72daf7]
libexec/mysqld(_ZN7handler13ha_update_rowEPKhPh+0x64)[0x68c9c4]
libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_orderm15enum_duplicatesbPmSB_+0xf21)[0x631d81]
libexec/mysqld(_Z21mysql_execute_commandP3THD+0x1c51)[0x5a4481]
libexec/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x3d0)[0x628d20]
libexec/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0x6f)[0x629a3f]
libexec/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0xdf)[0x629cdf]
libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x8d2)[0x5a8cf2]
libexec/mysqld(_Z10do_commandP3THD+0xc2)[0x5a95d2]
libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x154)[0x59cb64]
libexec/mysqld(handle_one_connection+0x9)[0x59cc09]
/lib64/libpthread.so.0[0x300b40673d]
/lib64/libc.so.6(clone+0x6d)[0x300acd3d1d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x1ab9bc48 = UPDATE sbtest_1 SET some_id= ? WHERE id = ?
thd->thread_id=18
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Changed in percona-server:
milestone: none → 5.5-20beta

I understand the crash.

The crash doesn't relate to adaptive_hash_index_partitions at all.

It is bug of split_buf_pool_mutex. And it affects 5.5.x only.

https://code.launchpad.net/~percona-dev/percona-server/5.5.7

22. By kinoyasu <kinoyasu@gauntlet4> 1 minute ago
    fix bug688866

Changed in percona-server:
status: Confirmed → Fix Committed
Vadim Tkachenko (vadim-tk) wrote :

it works now, bug is resolved.

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