Bug #42331 Falcon and trigger: crash if shutdown
Submitted: 25 Jan 2009 19:52 Modified: 6 Mar 2009 8:51
Reporter: Peter Gulutzan Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:6.0.10-alpha-debug OS:Linux (SUSE 10.0 / 32-bit)
Assigned to: Sergey Vojtovich CPU Architecture:Any
Tags: F_SHUTDOWN

[25 Jan 2009 19:52] Peter Gulutzan
Description:
I create a Falcon table.
I create a trigger.
I say 'mysqladmin shutdown'.
Crash.

I suspect this differs from
Bug#42184 Crash in Falcon on shutdown
because the stack is not the same.

How to repeat:
I started with a clean server, that is, nothing had
been added in any user databases.

On mysql client, say:

use test
create table t (s1 smallint) engine=falcon;
create trigger tbi before insert on t for each row set @a=5;

Now exit the client and say 'mysqladmin shutdown'.

Example run (as seen on client):

pgulutzan@linux:~> /usr/local/mysql/bin/mysql --user=root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 6.0.10-alpha-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use test
Database changed
mysql> create table t (s1 smallint) engine=falcon;
Query OK, 0 rows affected (0.09 sec)

mysql> create trigger tbi before insert on t for each row set @a=5;
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye
pgulutzan@linux:~> /usr/local/mysql/bin/mysqladmin --user=root shutdown

Example run (as seen on server):

linux:/usr/local/mysql/var # /usr/local/mysql/libexec/mysqld --user=root --skip-networking
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
090125 12:49:40  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
090125 12:49:41  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
090125 12:49:41  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
090125 12:49:42  InnoDB: Started; log sequence number 0 0
090125 12:49:42 [Note] Event Scheduler: Loaded 0 events
090125 12:49:42 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '6.0.10-alpha-debug'  socket: '/tmp/mysql.sock'  port: 0  Source distribution
090125 12:50:20 [Note] Got signal 15 to shutdown mysqld
090125 12:50:20 [Note] /usr/local/mysql/libexec/mysqld: Normal shutdown

090125 12:50:20 [Note] Event Scheduler: Purging the queue. 0 events
090125 12:50:23  InnoDB: Starting shutdown...
090125 12:50:23  InnoDB: Shutdown completed; log sequence number 0 46409
090125 12:50:24 [Warning] Forcing shutdown of 2 plugins
090125 12:50:24 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete

090125 12:50:24 - 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=2408550287
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2681723 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x0
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 = (nil) thread_stack 0x30c00
/usr/local/mysql/libexec/mysqld(my_print_stacktrace+0x32) [0x8909bd0]
/usr/local/mysql/libexec/mysqld(handle_segfault+0x2cb) [0x8317257]
[0xb7f41420]
/usr/local/mysql/libexec/mysqld [0x89084ef]
/usr/local/mysql/libexec/mysqld(my_hash_iterate+0x3c) [0x891ad09]
/usr/local/mysql/libexec/mysqld(safe_mutex_free_deadlock_data+0x6f) [0x89080b1]
/usr/local/mysql/libexec/mysqld(safe_mutex_destroy+0x12e) [0x8907fc2]
/usr/local/mysql/libexec/mysqld [0x831618d]
/usr/local/mysql/libexec/mysqld [0x831645c]
/usr/local/mysql/libexec/mysqld(print_signal_warning+0) [0x831b26c]
/lib/libc.so.6(__libc_start_main+0xdc) [0xb7c70f9c]
/usr/local/mysql/libexec/mysqld [0x8230551]
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.
[25 Jan 2009 20:50] Sveta Smirnova
Thank you for the report.

Verified as described.
[26 Jan 2009 15:40] Kevin Lewis
Sergey,  This call stack is not in Falcon.  Can you determine what went wrong and if there is anything that falcon can do about it?
[6 Mar 2009 8:47] Sveta Smirnova
I can not repeat it anymore.
[6 Mar 2009 8:51] Sergey Vojtovich
Was unable to repeat this bug. Probably relevant bugs: BUG#42109 and BUG#43048.