MySQL Bugs: #43954: falcon_bug_22150 sometimes crashes the server

Bug #43954	falcon_bug_22150 sometimes crashes the server
Submitted:	30 Mar 2009 8:49	Modified:	1 Apr 2009 21:26
Reporter:	Olav Sandstå	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0.11-alpha	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	F_INDEX, pushbuild

Description:
When running falcon_bug_22150 the server sometimes crashes. The test log contains:

CURRENT_TEST: falcon.falcon_bug_22150
mysqltest: At line 62: query 'CALL p1()' failed: 2006: MySQL server has gone away

The result from queries just before the failure was:
< snip >
DECLARE v1 int default 0;
DECLARE v2 int;
DECLARE CONTINUE HANDLER FOR 1020 BEGIN END;
DECLARE CONTINUE HANDLER FOR 1213 BEGIN END;
WHILE v1 < 2500 DO
/* SELECT 'insert', v1; */
INSERT INTO t1 VALUES (v1);
SET v2 = rand() * 10000;
UPDATE t1 SET a = v2 WHERE a = v1;
/* SELECT ' update', v1; */
SET v1 = v1 + 1;
IF v1 MOD 50 = 0 THEN
/* SELECT ' delete'; */
DELETE FROM t1;
END IF;
END WHILE;
END//
# Sent call p1() to the server but do not pull the results
CALL p1();
# Switch to connection conn1

How to repeat:
Seen sometimes when running test falcon_bug_22150.

Suggested fix:
Server should not crash

Chris, Can you fire off xeno to run this over and over until it fails?  We need to get a call stack or catch it in the debugger.  At this point we don't even know what the major category is.

By repeating falcon_bug_22150 "many times" I got the following crash:

[Falcon] Error: assertion (level == 0) failed at line 199 in file IndexPage.cpp

The call stacks looks like:

current thread: t@12
  [1] __lwp_kill(0xc, 0x6, 0xffffffff96fd2920, 0x0, 0x0, 0x0), at 0xfffffd7fff14
318a 
  [2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff13e1b3 
=>[3] my_write_core(sig = 6), line 309 in "stacktrace.c"
  [4] handle_segfault(sig = 6), line 2693 in "mysqld.cc"
  [5] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff1400b6 
  [6] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff1353a2 
  [7] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff135588 
  ---- called from signal handler with signal 6 (SIGABRT) ------
  [8] __lwp_kill(0xc, 0x6, 0xffffffff96fd2920, 0x0, 0xfefefeffffffffff, 0x10000)
, at 0xfffffd7fff14318a 
  [9] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff13e1b3 
  [10] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff0ecd79 
  [11] Error::debugBreak(), line 94 in "Error.cpp"
  [12] Error::error(string = 0xfce5ea "assertion (%s) failed at line %d in file 
%s\n", ...), line 71 in "Error.cpp"
  [13] Error::assertionFailed(text = 0xff329b "level == 0", fileName = 0xff32a6 
"IndexPage.cpp", line = 199), line 78 in "Error.cpp"
  [14] IndexPage::findNodeInLeaf(this = 0x20f6000, indexKey = 0xfffffd7ffd9a5890
, foundKey = (nil)), line 199 in "IndexPage.cpp"
  [15] IndexRootPage::addIndexEntry(dbb = 0x17b3618, indexId = 0, key = 0xfffffd
7ffd9a5890, recordNumber = 405, transId = 0), line 138 in "IndexRootPage.cpp"
  [16] IndexRootPage::indexMerge(dbb = 0x17b3618, indexId = 0, logRecord = 0xfff
ffd7ffd9a8b28, transId = 0), line 887 in "IndexRootPage.cpp"
  [17] SRLUpdateIndex::execute(this = 0xfffffd7ffd9a8b28), line 217 in "SRLUpdat
eIndex.cpp"
  [18] SRLUpdateIndex::commit(this = 0xfffffd7ffd9a8b28), line 195 in "SRLUpdate
Index.cpp"
  [19] SerialLogTransaction::commit(this = 0x19d2d38), line 92 in "SerialLogTran
saction.cpp"
  [20] SerialLogTransaction::doAction(this = 0x19d2d38), line 158 in "SerialLogT
ransaction.cpp"
  [21] Gopher::gopherThread(this = 0x1848500), line 71 in "Gopher.cpp"
  [22] Gopher::gopherThread(arg = 0x1848500), line 37 in "Gopher.cpp"
  [23] Thread::thread(this = 0x18526c8), line 167 in "Thread.cpp"
  [24] Thread::thread(parameter = 0x18526c8), line 146 in "Thread.cpp"
  [25] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff13fd7b 
  [26] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff13ffb0 

Core file etc can be made available for inspection.

This is the same assert and call stack as in Bug#43800.

This is a duplicate of Bug#43765, as was Bug#43800.  All three have the same call stack, except that 43765 does not seem to mention the exact assertion.