MySQL Bugs: #36972: falcon_bug_34890.test fails in pushbuild

Bug #36972	falcon_bug_34890.test fails in pushbuild
Submitted:	26 May 2008 14:45	Modified:	23 Apr 2009 21:07
Reporter:	Ingo Strüwing	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0	OS:	Any
Assigned to:	Vladislav Vaintroub	CPU Architecture:	Any
Tags:	F_UNKNOWN, pushbuild, sporadic, test failure

Description:
Seen on win2003-x86 in 6.0-engines-merge:

falcon.falcon_bug_34890        [ fail ]

mysqltest: At line 30: query 'connect  conn3,localhost,root,,' failed: 2013: Lost connection to MySQL server at 'reading authorization packet', system error: 0

The result from queries just before the failure was:
*** Bug #34890 ***
SET @@storage_engine = 'Falcon';
DROP TABLE IF EXISTS t1;
DROP PROCEDURE IF EXISTS p1;
# Establish connection conn1 (user = root)
SET @@autocommit = 1;
# Establish connection conn2 (user = root)
SET @@autocommit = 1;
# Establish connection conn3 (user = root)

More results from queries before failure can be found in e:\pb\mysql-6.0-engines-merge\1\mysql-6.0.6-alpha-pb1\mysql-test\var-falcon-7\log\falcon_bug_34890.log

I will disable the test case for now. Please re-enable after fix.

How to repeat:
See pushbuild.

Hakan,  This testcase is failing very intermittently.  But we do not have a call stack yet.  Maybe it should be moved to the falcon-team suite?  Can you try to reproduce it and get a call stack for us.?  

The most recent failure;
    2008-05-23 13:57:18 	mysql-6.0-falcon-team 	rh-x86-32
was an error 1114 (HA_ERR_RECORD_FILE_FULL,ER_RECORD_FILE_FULL), which can come from Falcon as StorageErrorDeviceFull.  So that is probably a test environment problem.  But the other pushbuild failures are all 'Lost connection to MySQL server'.

This test is still failing every now and then in Pushbuild. Most of the recent failures have the following signature:

--- --- signature start --- ---
falcon.falcon_bug_34890        [ fail ]

mysqltest: At line 91: query 'CALL p1()' failed: 2006: MySQL server has gone away

The result from queries just before the failure was:
< snip >
SET my_uuid = UUID();
INSERT INTO t1 (t1_uuid) VALUES (my_uuid);
DELETE FROM t1 WHERE t1_uuid IN (my_uuid);
SET my_count = my_count + 1;
end while;
end//
# Switch to connection conn1
# Send call p1() to the server but do not pull the results
CALL p1();
# Switch to connection conn2
# Send call p1() to the server but do not pull the results
CALL p1();
# Switch to connection conn3
# Send call p1() to the server but do not pull the results
CALL p1();
# Switch to connection conn4
# Send call p1() to the server but do not pull the results
CALL p1();
# Switch to connection default
CALL p1();

More results from queries before failure can be found in /dev/shm/var-falcon-112/log/falcon_bug_34890.log

Stopping All Servers
Restoring snapshot of databases
--- --- signature end --- ---

Recent failures observed in Pushbuild include (but are not limited to):

Push date               Branch
-------------------     ---------------------------
2008-09-14 19:33:00	bzr_mysql-6.0-falcon-team
2008-09-12 18:12:00	bzr_mysql-6.0-opt
2008-08-14 04:31:00	bzr_mysql-6.0-falcon-chris
2008-08-13 08:53:00	bzr_mysql-6.0-falcon-team
2008-07-25 15:01:00	bzr_mysql-6.0

The test has failed on a variety of platforms including Debian, Windows, Solaris, RedHat.

Stack trace from Pushbuild failure (failure signature as described in previous comment) on 'debx86-b' 'double whopper' Sep 14 2008 19:33:22 (Pushbuild's timezone), revid 'hky@sun.com-20080914140945-vvws8wklska3nktp':

CURRENT_TEST: falcon.falcon_bug_34890
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(my_print_stacktrace+0x26)[0x89284f7]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(handle_segfault+0x2dc)[0x82ef30c]
[0xffffe420]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN10RecordLeaf5fetchEi+0x4b)[0x863eb77]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN5Table9fetchNextEi+0x19a)[0x85c0afa]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN15StorageDatabase7nextRowEP12StorageTableib+0x59)[0x85ab629]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN12StorageTable4nextEib+0x3a)[0x85b1784]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN16StorageInterface8rnd_nextEPh+0x92)[0x85a3944]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z13rr_sequentialP14st_read_record+0x71)[0x84148c9]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z12mysql_deleteP3THDP10TABLE_LISTP4ItemP11st_sql_listyyb+0xf60)[0x83ae5dc]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z21mysql_execute_commandP3THD+0x3766)[0x8302d78]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x11)[0x84ab951]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x1b6)[0x84ac254]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN13sp_instr_stmt7executeEP3THDPj+0x1af)[0x84ac8fb]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN7sp_head7executeEP3THD+0x4c5)[0x84ae89f]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x75f)[0x84af57f]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z21mysql_execute_commandP3THD+0x739d)[0x83069af]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x22b)[0x8308bdd]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x8b9)[0x8309621]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(_Z10do_commandP3THD+0x236)[0x830a930]
/data0/pushbuild/pb1/pb/bzr_mysql-6.0-falcon-team/87/mysql-6.0.8-alpha-pb87/sql/mysqld(handle_one_connection+0x119)[0x82f7f69]
/lib/tls/libpthread.so.0[0x400220bd]
/lib/tls/libc.so.6(__clone+0x5e)[0x402609ee]
080915  0:50:47 - 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=1048576
read_buffer_size=131072
max_used_connections=5
max_threads=151
thread_count=5
connection_count=5
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 59998 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x9c22bc8
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 = 0x4f934048 thread_stack 0x30c00
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x9cacc90 = DELETE FROM t1 WHERE t1_uuid IN ( NAME_CONST('my_uuid',_latin1'309c738e-82a7-11dd-8fca-00d06806ad18'))
thd->thread_id=219
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.
Writing a core file

The error did not happen since about a month.
I run the test  multiple times - no error. I increased the number of connections in the test case to 8 and run multiple times - no error.

Gence, closing as non-reproducible.

It still happens: http://tinyurl.com/d9vy5m

Looks like temporarily glitch that was fixed with Bug#43765.