MySQL Bugs: #42274: Running iuds6.tst leads to assertion in Falcon

Bug #42274	Running iuds6.tst leads to assertion in Falcon
Submitted:	22 Jan 2009 18:25	Modified:	7 May 2009 15:53
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S1 (Critical)
Version:		OS:	Linux
Assigned to:	Christopher Powers	CPU Architecture:	Any
Tags:	F_CHILL THAW

Description:
Running iuds6.tst is crashing Falcon

How to repeat:
run iuds6.tst from mysql-test-extra

[Falcon] Error: assertion (prune->useCount == 1) failed at line 149 in file RecordLeaf.cpp

090121 14:27:55 - mysqld got signal 6 ;
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=1048576
read_buffer_size=131072
max_used_connections=56
max_threads=151
thread_count=50
connection_count=49
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 60619 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
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(my_print_stacktrace+0x29) [0xa966b9]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(handle_segfault+0x339) [0x6503c9]
/lib64/libpthread.so.0 [0x2af40fc76c00]
/lib64/libpthread.so.0(raise+0x2d) [0x2af40fc76aad]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Error::error(char const*, ...)+0x102) [0x84e9c2]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(RecordLeaf::pruneRecords(Table*, int, RecordScavenge*)+0xbb) [0x8c86fb]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(RecordGroup::pruneRecords(Table*, int, RecordScavenge*)+0x49) [0x9217c9]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Table::pruneRecords(RecordScavenge*)+0x5b) [0x861c6b]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Database::pruneRecords(RecordScavenge*)+0x4b) [0x88a68b]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Database::scavengeRecords()+0x4f) [0x88a75f]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Database::scavenge()+0xab) [0x88e01b]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Database::scavengerThreadMain(void*)+0x42) [0x8902c2]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Thread::thread()+0x94) [0x86f154]
/data0/fsqa/cb/mysql-6.0.10-alpha/sql/mysqld(Thread::thread(void*)+0x9) [0x86f339]
/lib64/libpthread.so.0 [0x2af40fc6f143]
/lib64/libc.so.6(__clone+0x6d) [0x2af4103a88cd]
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.
Writing a core file

I get the assertion when running DBT2, too:

Version: '6.0.10-alpha'  socket: '/tmp/mysql.sock'  port: 3306  'MySQL-Community-Server'
[Falcon] Error: assertion (prune->useCount == 1) failed at line 149 in file RecordLeaf.cpp

090116 16:47:26 - mysqld got signal 6 ;
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=1048576
max_used_connections=99
max_threads=1601
thread_count=99
connection_count=99
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4943537 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
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(my_print_stacktrace+0x2e) [0xaa9d5e]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(handle_segfault+0x336) [0x655ed6]
/lib64/libpthread.so.0 [0x2b22aca98c00]
/lib64/libpthread.so.0(raise+0x2d) [0x2b22aca98aad]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Error::error(char const*, ...)+0xf9) [0x85a999]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(RecordLeaf::pruneRecords(Table*, int, RecordScavenge*)+0xc4) [0x8d6d54]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(RecordGroup::pruneRecords(Table*, int, RecordScavenge*)+0x50) [0x9313f0]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(RecordGroup::pruneRecords(Table*, int, RecordScavenge*)+0x50) [0x9313f0]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(RecordGroup::pruneRecords(Table*, int, RecordScavenge*)+0x50) [0x9313f0]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Table::pruneRecords(RecordScavenge*)+0x60) [0x86e270]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Database::pruneRecords(RecordScavenge*)+0x51) [0x897b61]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Database::scavengeRecords()+0x57) [0x897c37]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Database::scavenge()+0xba) [0x89b4aa]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Database::scavengerThreadMain(void*)+0x45) [0x89d7e5]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Thread::thread()+0x95) [0x87bb55]
/data0/work/mysql/mysql-6.0-falcon/sql/mysqld(Thread::thread(void*)+0x11) [0x87bd51]
/lib64/libpthread.so.0 [0x2b22aca91143]
/lib64/libc.so.6(__clone+0x6d) [0x2b22ad1ca8cd]

This assert has been seen many times with the new scavenger

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/63991

2972 Christopher Powers	2009-01-24
      Bug #41663, "Falcon assertion (deferredIndex->virtualOffset) failed at
Index.cpp:264"
      
      Don't try to chill empty deferred indexes.

This patch also eliminates the assert in Bug#42274 and instead prevents the prune from happening for this record chain in the current cycle.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/64062

2976 Christopher Powers	2009-01-26
      Bug #42274, "Running iuds6.tst leads to assertion in Falcon"
      
      Eliminate the use count assertion in RecordLeaf::pruneRecords().
      The occasional unexpected use count must still be resolved,
      but this is not a critical issue. The record chain can simply
      be skipped during the scavenge process.

Pushed into 6.0.10-alpha (revid:alik@sun.com-20090211182317-uagkyj01fk30p1f8) (version source revid:vvaintroub@mysql.com-20090126231319-7b6yu4zqp2xfxuqg) (merge vers: 6.0.10-alpha) (pib:6)

Internal/test failure. No changelog entry required.