| Bug #36473 | Assertion "! is_set()" fails in Diagnostics_area::set_ok_status with Falcon | ||
|---|---|---|---|
| Submitted: | 2 May 2008 13:35 | Modified: | 9 Jan 2009 14:08 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Falcon storage engine | Severity: | S1 (Critical) |
| Version: | 6.0-bzr-debug, 6.0.5, 5.1-maria | OS: | Any |
| Assigned to: | Konstantin Osipov | CPU Architecture: | Any |
| Tags: | F_ERROR HANDLING | ||
[2 May 2008 13:35]
Philip Stoev
[27 Aug 2008 7:11]
Valeriy Kravchuk
Verified with recent 6.0.7-alpha-debug on Linux:
openxs@suse:/home2/openxs/dbs/6.0> bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 6.0.7-alpha-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> drop table t1;
ERROR 1051 (42S02): Unknown table 't1'
mysql> create table t1
-> (
-> `a` tinyint(4) NOT NULL auto_increment,
-> primary key (`a`)
-> ) engine = Falcon;
Query OK, 0 rows affected (0.13 sec)
mysql> set @@sql_mode='strict_all_tables';
Query OK, 0 rows affected (0.00 sec)
mysql> set auto_increment_increment=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> set auto_increment_offset=700;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into t1 values(null);
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
mysql> 080802 07:31:37 mysqld_safe Number of processes running now: 0
080802 07:31:37 mysqld_safe mysqld restarted
mysql> exit
Bye
openxs@suse:/home2/openxs/dbs/6.0> tail -70 var/suse.err
080729 1:20:08 [Note] Event Scheduler: Loaded 0 events
080729 1:20:08 [Note] /home2/openxs/dbs/6.0/libexec/mysqld: ready for connections.
Version: '6.0.7-alpha-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
080729 1:20:26 [Note] Got signal 15 to shutdown mysqld
080729 1:20:26 [Note] /home2/openxs/dbs/6.0/libexec/mysqld: Normal shutdown
080729 1:20:26 [Note] Event Scheduler: Purging the queue. 0 events
080729 1:20:26 InnoDB: Starting shutdown...
080729 1:20:27 InnoDB: Shutdown completed; log sequence number 0 48117
080729 1:20:27 [Note] /home2/openxs/dbs/6.0/libexec/mysqld: Shutdown complete
080729 01:20:28 mysqld_safe mysqld from pid file /home2/openxs/dbs/6.0/var/suse.pid ended
080802 07:31:11 mysqld_safe Starting mysqld daemon with databases from /home2/openxs/dbs/6.0/var
080802 7:31:15 InnoDB: Started; log sequence number 0 48117
080802 7:31:16 [Note] Event Scheduler: Loaded 0 events
080802 7:31:16 [Note] /home2/openxs/dbs/6.0/libexec/mysqld: ready for connections.
Version: '6.0.7-alpha-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
mysqld: sql_class.cc:411: void Diagnostics_area::set_ok_status(THD*, long long unsigned int, long long unsigned int, const char*): Assertion `! is_set()' failed.
/home2/openxs/dbs/6.0/libexec/mysqld(my_print_stacktrace+0x29)[0x88e8f34]
/home2/openxs/dbs/6.0/libexec/mysqld(handle_segfault+0x271)[0x82ec669]
[0xffffe420]
/lib/tls/libc.so.6(abort+0x1a5)[0x40180b75]
/lib/tls/libc.so.6(__assert_fail+0x103)[0x40178903]
/home2/openxs/dbs/6.0/libexec/mysqld(_ZN16Diagnostics_area13set_ok_statusEP3THDyyPKc+0x74)[0x82d2f54]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z5my_okP3THDyyPKc+0x58)[0x821a0b8]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0x1093)[0x838c355]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x27cf)[0x82ff411]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x1d0)[0x8306c28]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x871)[0x82fb377]
/home2/openxs/dbs/6.0/libexec/mysqld(_Z10do_commandP3THD+0x229)[0x82fa8fd]
/home2/openxs/dbs/6.0/libexec/mysqld(handle_one_connection+0x125)[0x82f8009]
/lib/tls/libpthread.so.0[0x40050aa7]
/lib/tls/libc.so.6(__clone+0x5e)[0x40211c2e]
080802 7:31:36 - mysqld got signal 6 ;
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=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337792 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x9b21d80
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 = 0x47ebf430 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x9b78f50 = insert into t1 values(null)
thd->thread_id=1
thd->killed=KILL_BAD_DATA
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.
080802 07:31:37 mysqld_safe Number of processes running now: 0
080802 07:31:37 mysqld_safe mysqld restarted
080802 7:31:37 InnoDB: Started; log sequence number 0 48117
080802 7:31:37 [Note] Event Scheduler: Loaded 0 events
080802 7:31:37 [Note] /home2/openxs/dbs/6.0/libexec/mysqld: ready for connections.
Version: '6.0.7-alpha-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
openxs@suse:/home2/openxs/dbs/6.0>
[29 Sep 2008 18:02]
Philip Stoev
This also happens with Maria.
#8 0x003df57e in __assert_fail () from /lib/libc.so.6
#9 0x08299902 in Diagnostics_area::set_ok_status (this=0xad7c5db0, thd=0xad7c5008, affected_rows_arg=0, last_insert_id_arg=0, message_arg=0x0)
at sql_class.cc:411
#10 0x081dabc0 in my_ok (thd=0xad7c5008, affected_rows=0, id=0, message=0x0) at sql_class.h:2387
#11 0x082c5709 in mysql_execute_command (thd=0xad7c5008) at sql_parse.cc:3451
#12 0x082ca6b5 in mysql_parse (thd=0xad7c5008, inBuf=0x9dd40e0 "LOCK TABLES `C` WRITE CONCURRENT", length=32, found_semicolon=0xa79f2270)
at sql_parse.cc:5856
#13 0x082cb0ff in dispatch_command (command=COM_QUERY, thd=0xad7c5008, packet=0xad7c6e89 "LOCK TABLES `C` WRITE CONCURRENT", packet_length=32)
at sql_parse.cc:1120
#14 0x082cc412 in do_command (thd=0xad7c5008) at sql_parse.cc:807
#15 0x082b9e53 in handle_one_connection (arg=0xad7c5008) at sql_connect.cc:1153
#16 0x0057d32f in start_thread () from /lib/libpthread.so.0
#17 0x0049a27e in clone () from /lib/libc.so.6
[2 Oct 2008 21:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/55146 2721 Konstantin Osipov 2008-10-03 A fix and a test case for Bug#36473 Assertion "! is_set()" fails in Diagnostics_area::set_ok_status with Falcon. When running in strict mode, update_auto_increment() function may return an error. In case of Bug#36473 the error was due to an out of range auto increment value for a TINYINT column. Falcon handler implementation did not check for the return value and that led to an attempt to commit statement transaction in the server and return success status to the user. Fix by checking the return value of update_auto_increment().
[2 Oct 2008 21:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/55147 2721 Konstantin Osipov 2008-10-03 A fix and a test case for Bug#36473 Assertion "! is_set()" fails in Diagnostics_area::set_ok_status with Falcon. When running in strict mode, update_auto_increment() function may return an error. In case of Bug#36473 the error was due to an out of range auto increment value for a TINYINT column. Falcon handler implementation did not check for the return value and that led to an attempt to commit statement transaction in the server and return success status to the user. Fix by checking the return value of update_auto_increment().
[24 Oct 2008 1:18]
Bugs System
Pushed into 6.0.8-alpha (revid:kostja@sun.com-20081002210539-93rrixc932bdj5t3) (version source revid:kostja@sun.com-20081002210539-93rrixc932bdj5t3) (pib:5)
[9 Jan 2009 14:08]
MC Brown
A note has been added to the 6.0.8 changelog: Running in strict mode, with a auto_increment_increment and auto_increment_offset set to a value larger than supportedf by the specified auto increment column within a Falcon table, a crash would occur
