Bug #30437 repeatable crash with delete statement!!!

• Submitted: 15 Aug 2007 14:31
• Modified: 16 Aug 2007 13:51
• Reporter: Shane Bester (Platinum Quality Contributor)
• Status: Can't repeat
• Category: MySQL Server: Falcon storage engine
• Severity: S1 (Critical)
• Version: 6.0.2BK
• OS: Any
• Assigned to: Christoffer Hall
• CPU Architecture: Any
• Tags: crash

[15 Aug 2007 14:31] Shane Bester

Description:
Version: '6.0.2-alpha-debug'  socket: '/tmp/mysql.sock'  port: 3306  yes
070815 16:08:03 - 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=8388572
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337602 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8e5cf18
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...
Cannot determine thread, fp=0x42a8bc6c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x82100db handle_segfault + 541
0x83c12af _ZN11Transaction12removeRecordEP13RecordVersion + 55
0x83bd5b1 _ZN5Table12unlockRecordEP13RecordVersionb + 87
0x83bd548 _ZN5Table12unlockRecordEi + 62
0x83b21bc _ZN12StorageTable9unlockRowEv + 46
0x83a811b _ZN16StorageInterface10index_nextEPh + 435
0x83a7efa _ZN16StorageInterface16read_range_firstEPK12st_key_rangeS2_bb + 660
0x82fd38f _ZN7handler22read_multi_range_firstEPP18st_key_multi_rangeS1_jbP17st_handler_buffer + 253
0x82eb26e _ZN18QUICK_RANGE_SELECT8get_nextEv + 568
0x82f3abb _Z8rr_quickP14st_read_record + 89
0x82f534c _Z13find_all_keysP13st_sort_paramP10SQL_SELECTPPhP11st_io_cacheS6_S6_ + 1092
0x82f4710 _Z8filesortP3THDP8st_tableP13st_sort_fieldjP10SQL_SELECTybPy + 1200
0x82a25a4 _Z12mysql_deleteP3THDP13st_table_listP4ItemP11st_sql_listyyb + 2532
0x821f491 _Z21mysql_execute_commandP3THD + 12041
0x8225a21 _Z11mysql_parseP3THDPKcjPS2_ + 339
0x821b06d _Z16dispatch_command19enum_server_commandP3THDPcj + 2325
0x821a74c _Z10do_commandP3THD + 612
0x82192b3 handle_one_connection + 253
0x40250aa7 _end + 933376311
0x401e6c2e _end + 932942526
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/refman/5.1/en/resolve-stack-dump.html
and follow instructions on how to resolve the stack trace.
Resolved stack trace is much more helpful in diagnosing the
problem, so please do resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8e8c0f8 = delete from `marker_4142` where `c3` <> 123456 order by `c4` limit 581
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
stay tuned for more.

Suggested fix:
.

[15 Aug 2007 14:43] MySQL Verification Team

#---testcase---
drop table if exists `t1`;
create table `t1`(`c1` int auto_increment not null primary key,`c2` varchar(1000),`c3` bigint,`c4` bigint,key(`c3`,`c4`))engine=falcon;
insert into `t1`(`c2`,`c3`,`c4`) values ('a',123456,1);
delete from `t1` where `c3` <> 123456;

[16 Aug 2007 12:40] MySQL Verification Team

Christopher, my old 6.0.1 build doesn't crash, and neither does the build team's build.  Still, Johan and myself built source yesterday, and it crashes.  I used mysql.bkbits.com, the mysql-6.0-falcon tree. Perhaps it's some new bug?

[16 Aug 2007 12:48] Christoffer Hall

My tests are done with a fresh pull. From late yesterday.

[16 Aug 2007 13:49] Christoffer Hall

And with pull from 5 minutes ago. BK came back up.

[16 Aug 2007 16:39] MySQL Verification Team

I still get from mysql.bkbits.net tree:

(gdb) where
#0  0xffffe410 in ?? ()
#1  0x4115918c in ?? ()
#2  0x0000000b in ?? ()
#3  0x000020d8 in ?? ()
#4  0x40253838 in pthread_kill () from /lib/tls/libpthread.so.0
#5  0x082f1857 in write_core ()
#6  0x081ebc9b in handle_segfault ()
#7  <signal handler called>
#8  0x0833d5cf in Transaction::removeRecord ()
#9  0x083398d1 in Table::unlockRecord ()
#10 0x08339868 in Table::unlockRecord ()
#11 0x0832e4dc in StorageTable::unlockRow ()
#12 0x08325505 in StorageInterface::index_next ()
#13 0x0832539a in StorageInterface::read_range_first ()
#14 0x082aaf74 in handler::read_multi_range_first ()
#15 0x0829dda1 in QUICK_RANGE_SELECT::get_next ()
#16 0x082a3f6b in end_read_record ()
#17 0x0826795e in mysql_delete ()
#18 0x081f8337 in mysql_execute_command ()
#19 0x081fddf6 in mysql_parse ()
#20 0x081f4bbb in dispatch_command ()
#21 0x081f445e in do_command ()
#22 0x081f3507 in handle_one_connection ()
#23 0x40250aa7 in pthread_create () from /lib/tls/libpthread.so.0
#24 0x401e6c2e in clone () from /lib/tls/libc.so.6
(gdb) frame

I cannot run mysqld in gdb on this machine, so I cannot study it more.  Will try again, another time.

[16 Aug 2007 17:42] MySQL Verification Team

christopher, this can't be a build problem. Windows debug 6.0.2BK build crashed too. Attached a trace.

Attachment: 6.0.2_win_stack.txt (text/plain), 5.09 KiB.

[16 Aug 2007 17:50] MySQL Verification Team

"records" variable is NULL in the above dump.

[16 Aug 2007 17:59] Kevin Lewis

Shane,  you MUST test with today's code at bk-internal.mysql.com:/home/bk/mysql-5.1-falcon.  I checked in a change two days ago for Bug#30364 that very well may fix this crash.  That may be why nobody else can reproduce it.  I cannot either.  The source tree at mysql.bkbits.net is 13 days behind!