MySQL Bugs: #39940: Crash when creating backlog

Bug #39940	Crash when creating backlog
Submitted:	8 Oct 2008 18:54	Modified:	26 May 2010 17:50
Reporter:	Ann Harrison	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S2 (Serious)
Version:	falcon-team (6.0.7+)	OS:	Any
Assigned to:	Christopher Powers	CPU Architecture:	Any
Tags:	F_BACKLOG, pb2, pushbuild, test failure

Description:
Falcon crashes when creating a tablespace for the backlog.  The crash
is in SerialLog and the backlog tablespace shouldn't ever go there.

How to repeat:
Pull from the mysql-test-extra-6.0 tree and then use the command line from

https://inside.mysql.com/wiki/RandomQueryGeneratorTests#Falcon_Backlog

This test runs and crashes natively on Windows, however the data loading stage may take over half an hour. Please let me (Philip) know if this makes debugging inconvenient. 

Suggested fix:
If the tableSpaceId is -1, it's the backlog and gets special handling - should
be in dbb->isSectionInUse, probably.

This bug happens as soon as falcon backlog is activated, that is, as soon as there is a low-memory condition and chill/thaw is activated. The test creates one long-running transaction which must be backlogged once available memory is exhausted.

To reproduce with the random query generator, please see the falcon_backlog test in PushBuild2.

Failure symptoms from falcon_backlog test in Pushbuild 2:

# 05:42:57 Query: SELECT * FROM `table65536_falcon_int_autoinc` failed: 2013 Lost connection to MySQL server during query

Partial test log with stack trace (Linux):

(...)
Record Memory usage for FALCON_MASTER:
IO::createFile: creating file "_falcon_backlog.fts"
081031  7:42:57 - mysqld got signal 11 ;
(...)
Program terminated with signal 11, Segmentation fault.
#0  0x006be402 in __kernel_vsyscall ()
#0  0x006be402 in __kernel_vsyscall ()
#1  0x0089f067 in pthread_kill () from /lib/libpthread.so.0
#2  0x087f6ec2 in my_write_core (sig=11) at stacktrace.c:307
#3  0x082b1938 in handle_segfault (sig=11) at mysqld.cc:2673
#4  <signal handler called>
#5  0x085faae6 in SerialLog::getTableSpaceInfo (this=0xb731ad80, 
    tableSpaceId=-1) at SerialLog.cpp:1489
#6  0x085facec in SerialLog::sectionInUse (this=0xb731ad80, sectionId=0, 
    tableSpaceId=-1) at SerialLog.cpp:1290
#7  0x0858efa7 in Dbb::sectionInUse (this=0xa70007a8, sectionId=0)
    at Dbb.cpp:1254
#8  0x085f530e in Section::createSection (dbb=0xa70007a8, transId=0)
    at Section.cpp:125
#9  0x0856ffb3 in BackLog (this=0xb70d30c0, db=0xb72c1640, 
    fileName=0x89a7a55 "_falcon_backlog.fts") at BackLog.cpp:46
#10 0x08581d2a in Database::setLowMemory (this=0xb72c1640) at Database.cpp:2620
#11 0x08583978 in Database::retireRecords (this=0xb72c1640, forced=true)
    at Database.cpp:1841
#12 0x08583bff in Database::forceRecordScavenge (this=0xb72c1640)
    at Database.cpp:2511
#13 0x085cc593 in Record::allocRecordData (this=0xa858a8d0, length=773)
    at Record.cpp:928
#14 0x085ce40f in Record::setEncodedRecord (this=0xa858a8d0, 
    stream=0xb746c2c4, interlocked=false) at Record.cpp:707
#15 0x085599f3 in Table::update (this=0xb7437048, transaction=0xb7251ae0, 
    orgRecord=0xa858b9f0, stream=0xb746c2c4) at Table.cpp:3143
#16 0x0853f35b in StorageDatabase::updateRow (this=0xb70c0130, 
    storageConnection=0xb71698d0, table=0xb7437048, oldRecord=0xa858b9f0, 
    stream=0xb746c2c4) at StorageDatabase.cpp:688
#17 0x08545ff1 in StorageTable::updateRow (this=0xb7466d98, recordNumber=3427)
    at StorageTable.cpp:132
#18 0x08533086 in StorageInterface::update_row (this=0xb7f8c80, 
    oldData=0xb846110 "ÿÿ", newData=0xb844d00 "ÿÿ") at ha_falcon.cpp:1171
#19 0x083e3b81 in handler::ha_update_row (this=0xb7f8c80, 
    old_data=0xb846110 "ÿÿ", new_data=0xb844d00 "ÿÿ") at handler.cc:5378
#20 0x0836ebb3 in mysql_update (thd=0xb7d6818, table_list=0xb7e0768, 
    fields=@0xb7d7e18, values=@0xb7d8040, conds=0xb7e0fc0, order_num=0, 
    order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, 
    ignore=false) at sql_update.cc:649
#21 0x082c4d69 in mysql_execute_command (thd=0xb7d6818) at sql_parse.cc:2898
#22 0x082cabbb in mysql_parse (thd=0xb7d6818, 
    inBuf=0xb7e03f0 "UPDATE `table65536_falcon_int_autoinc` AS X SET `pk` = 'rasvhoaibmzbjlyzdmweontovxacgztcfegtycrdvcbxlfmgpuwkpvveplbhrsahtluchcsbzjwjtckeezqtmybmkbqmyznaktfcqxbhcnwvdivvlicvtdwgjgcbkjstyyirszjahbsotntj"..., length=311, 
    found_semicolon=0xb0681e80) at sql_parse.cc:5634

Seen on Linux, Solaris and Windows. The same test has also related in a deadlock on Solaris (revision vvaintroub@mysql.com-20081031002913-hg55ea1xjrimzx25), possibly caused by the same issue.

Tagging this bug as a Pushbuild 2 test failure.