MySQL Bugs: #38910: Backup: server crash for partitioned falcon on pushbuild sapsrv2 and Valgrind

Bug #38910	Backup: server crash for partitioned falcon on pushbuild sapsrv2 and Valgrind
Submitted:	20 Aug 2008 10:53	Modified:	10 Nov 2008 13:19
Reporter:	Jørgen Løland	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Backup	Severity:	S1 (Critical)
Version:	mysql-6.0-backup	OS:	Linux (SUSE 64-bit, x86_64)
Assigned to:	Sergey Vojtovich	CPU Architecture:	Any

Description:
backup_default.test fails on servers sapsrv2 and Valgrind. Both run Linux kernel 2.6.16 smp.

In both cases, the test fails when trying to backup a partitioned falcon table:

---- snip ----
mysqltest: At line 67: query 'BACKUP DATABASE db1 to 'bup_falcon.bak'' failed: 2013: Lost connection to MySQL server during query

The result from queries just before the failure was:
< snip >
DROP DATABASE db1;

Server should not crash for backup using default driver 
Partitioned Falcon tables
Test for bug#33566, bug#36792 

CREATE DATABASE db1;
USE db1;
CREATE TABLE partition_table (
int_column int(11), 
char_column char(5))
engine=falcon
PARTITION BY HASH (int_column);
INSERT INTO partition_table VALUES (0,'pVtIa');
INSERT INTO partition_table VALUES (5,'jTfSg');
INSERT INTO partition_table VALUES (20,'UezFi');
INSERT INTO partition_table VALUES (25,'cxmeH');
INSERT INTO partition_table VALUES (65,'lIuNS');
backup on partitioned falcon
BACKUP DATABASE db1 to 'bup_falcon.bak';

How to repeat:
Don't know yet. See pushbuild.

Test does not fail on Ubuntu on amd64, kernel 2.6.24. Both test machines that fail are x86 64 bit

Thank you for the bug report. Verified on Windows 32-bit too:

Version: '6.0.7-alpha-nt-debug-log'  socket: ''  port: 3600  Source distribution
080820  9:03:09 [Note] Backup: Starting backup process
080820  9:03:09 [Note] Backup: Backing up selected databases
Assertion failed: table->in_use == _current_thd(), file .\field.cc, line 6266
080820  9:03:22 - mysqld got exception 0x80000003 ;
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
thread_count=2
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337737 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x366b8f0
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...
00B8FED4    mysqld.exe!_NMSG_WRITE()[crt0msg.c:195]
00B7C00A    mysqld.exe!abort()[abort.c:44]
00B76C32    mysqld.exe!_assert()[assert.c:306]
00436BF0    mysqld.exe!Field_string::store()[field.cc:6266]
009D4951    mysqld.exe!StorageInterface::decodeRecord()[ha_falcon.cpp:2818]
009CD67D    mysqld.exe!StorageInterface::rnd_next()[ha_falcon.cpp:603]
004601AB    mysqld.exe!ha_partition::rnd_next()[ha_partition.cc:3297]
0090084D    mysqld.exe!default_backup::Backup::get_data()[be_default.cc:398]
008FE5F0    mysqld.exe!backup::Backup_pump::pump()[data_backup.cc:1212]
008FD325    mysqld.exe!backup::Scheduler::step()[data_backup.cc:721]
008FCDF7    mysqld.exe!backup::write_table_data()[data_backup.cc:553]
008EE6B9    mysqld.exe!Backup_restore_ctx::do_backup()[kernel.cc:844]
008ED1CC    mysqld.exe!execute_backup_command()[kernel.cc:178]
0065F1B7    mysqld.exe!mysql_execute_command()[sql_parse.cc:2266]
006680BD    mysqld.exe!mysql_parse()[sql_parse.cc:5845]
0065D3D5    mysqld.exe!dispatch_command()[sql_parse.cc:1120]
0065CC0D    mysqld.exe!do_command()[sql_parse.cc:807]
0076CBE7    mysqld.exe!handle_one_connection()[sql_connect.cc:1153]
008497CD    mysqld.exe!pthread_start()[my_winthread.c:86]
00B7F607    mysqld.exe!_threadstart()[thread.c:196]
7C80B713    kernel32.dll!GetModuleFileNameA()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 036DDFD0=BACKUP DATABASE db1 to 'bup_falcon.bak'
thd->thread_id=1
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.

I think the bug reported for windows above is the same bug as Bug#33566. The latest backup branch has a fix for that bug. Changing version to mysql-6.0-backup

Resetting status to open

Indeed mysql-6.0-backup on FC 8 64-bit not presents the crash:

mysql> INSERT INTO partition_table VALUES (65,'lIuNS');
Query OK, 1 row affected (0.00 sec)

mysql> BACKUP DATABASE db1 to 'bup_falcon.bak';
+-----------+
| backup_id |
+-----------+
| 1         | 
+-----------+
1 row in set (0.10 sec)

mysql>

The test hasn't failed for a very long time in PB. Not sure what fixed it, but it can be closed.

I will set this to can't repeat. Please feel free to re-open the bug report when baviour occurs again.

Test does not fail in pb because duplicate bug#39017 disabled the portions that failed.