Bug #54086 | Server crashing when connector/J testsuite run against it | ||
---|---|---|---|
Submitted: | 29 May 2010 18:46 | Modified: | 23 Sep 2010 8:41 |
Reporter: | Erica Moss | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server: General | Severity: | S1 (Critical) |
Version: | mysql-5.5.3-m3-winx64 | OS: | Windows (server 2003 x64) |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | connector/J crash |
[29 May 2010 18:46]
Erica Moss
[29 May 2010 18:50]
Erica Moss
query log leading to crash
Attachment: query log (application/octet-stream, text), 349.32 KiB.
[30 May 2010 10:44]
MySQL Verification Team
Hi Eric! Please upload the mysql server error log so we might see crash related info. does drop table crash?
[31 May 2010 5:47]
Tonci Grgin
Eric, please do run StatementRegressionTest from Eclipse where you can choose test by test.
[3 Jun 2010 5:06]
MySQL Verification Team
i doubt this bug is verified sufficiently...
[18 Jun 2010 8:42]
Tonci Grgin
Eric, I suggest you to try outside VM (real box) as I can not repeat the crash... My guess would be that something in VM timed out. Now, we are all aware what all can go wrong here but still. Log from the test that fails for you: 100618 10:39:11 5 Connect root@localhost on test 5 Query /* mysql-connector-java-5.1.13 ( Revision: mark.matthews@oracle.com-20100615210030-3r8bsc9bv0efe6gv ) */SHOW VARIABLES WHERE Variable_name ='language' OR Variable_name = 'net_write_timeout' OR Variable_name = 'interactive_timeout' OR Variable_name = 'wait_timeout' OR Variable_name = 'character_set_client' OR Variable_name = 'character_set_connection' OR Variable_name = 'character_set' OR Variable_name = 'character_set_server' OR Variable_name = 'tx_isolation' OR Variable_name = 'transaction_isolation' OR Variable_name = 'character_set_results' OR Variable_name = 'timezone' OR Variable_name = 'time_zone' OR Variable_name = 'system_time_zone' OR Variable_name = 'lower_case_table_names' OR Variable_name = 'max_allowed_packet' OR Variable_name = 'net_buffer_length' OR Variable_name = 'sql_mode' OR Variable_name = 'query_cache_type' OR Variable_name = 'query_cache_size' OR Variable_name = 'init_connect' 5 Query /* mysql-connector-java-5.1.13 ( Revision: mark.matthews@oracle.com-20100615210030-3r8bsc9bv0efe6gv ) */SELECT @@session.auto_increment_increment 5 Query SHOW COLLATION 5 Query SET character_set_results = NULL 5 Query SET autocommit=1 5 Query SET sql_mode='STRICT_TRANS_TABLES' 5 Query SELECT VERSION() 5 Query DROP TABLE IF EXISTS t1 5 Query CREATE TABLE t1 (id INTEGER, x INTEGER) ENGINE = INNODB 5 Query DROP TABLE IF EXISTS t2 5 Query CREATE TABLE t2 (id INTEGER, x INTEGER) ENGINE = INNODB 5 Query INSERT INTO t1 VALUES (0, 0) 5 Query SET autocommit=0 5 Query SELECT * FROM t1 WHERE id=0 FOR UPDATE 6 Connect root@localhost on test 6 Query /* mysql-connector-java-5.1.13 ( Revision: mark.matthews@oracle.com-20100615210030-3r8bsc9bv0efe6gv ) */SHOW VARIABLES WHERE Variable_name ='language' OR Variable_name = 'net_write_timeout' OR Variable_name = 'interactive_timeout' OR Variable_name = 'wait_timeout' OR Variable_name = 'character_set_client' OR Variable_name = 'character_set_connection' OR Variable_name = 'character_set' OR Variable_name = 'character_set_server' OR Variable_name = 'tx_isolation' OR Variable_name = 'transaction_isolation' OR Variable_name = 'character_set_results' OR Variable_name = 'timezone' OR Variable_name = 'time_zone' OR Variable_name = 'system_time_zone' OR Variable_name = 'lower_case_table_names' OR Variable_name = 'max_allowed_packet' OR Variable_name = 'net_buffer_length' OR Variable_name = 'sql_mode' OR Variable_name = 'query_cache_type' OR Variable_name = 'query_cache_size' OR Variable_name = 'init_connect' 6 Query /* mysql-connector-java-5.1.13 ( Revision: mark.matthews@oracle.com-20100615210030-3r8bsc9bv0efe6gv ) */SELECT @@session.auto_increment_increment 6 Query SHOW COLLATION 6 Query SET character_set_results = NULL 6 Query SET autocommit=1 6 Query SET sql_mode='STRICT_TRANS_TABLES' 6 Query SET autocommit=0 6 Query INSERT INTO t2 VALUES (1, 0) 6 Query SELECT * FROM t2 WHERE id=0 FOR UPDATE 6 Query INSERT INTO t2 VALUES (1, 0) 6 Query INSERT INTO t2 VALUES (2, 0) 6 Query UPDATE t1 SET x=2 WHERE id=0 100618 10:39:42 5 Query INSERT INTO t1 VALUES (0, 0) 5 Query SET autocommit=1 6 Quit 5 Query DROP TABLE IF EXISTS t1 5 Query DROP TABLE IF EXISTS t2 5 Quit
[18 Jun 2010 8:43]
Tonci Grgin
Error log (I did the shutdown after successful test): 100618 10:33:48 [Note] Buffered information: Performance schema disabled (reason: start parameters). 100618 10:33:48 [Note] Plugin 'FEDERATED' is disabled. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use Windows interlocked functions 100618 10:33:49 InnoDB: highest supported file format is Barracuda. 100618 10:33:49 InnoDB Plugin 1.0.6 started; log sequence number 44278 100618 10:33:49 [Note] Event Scheduler: Loaded 0 events 100618 10:33:49 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections. Version: '5.5.3-m3-community-log' socket: '' port: 5530 MySQL Community Server (GPL) 100618 10:40:08 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Normal shutdown 100618 10:40:08 [Note] Event Scheduler: Purging the queue. 0 events 100618 10:40:08 InnoDB: Starting shutdown... 100618 10:40:09 InnoDB: Shutdown completed; log sequence number 50780 100618 10:40:09 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete
[18 Jun 2010 8:56]
Tonci Grgin
And finally, the test itself, testDeadlockBatchBehavior() completes correctly, ie. exception is thrown where expected, junit run completes: the part that breaks intentionally: new Thread() { public void run() { try { deadlockStmt.addBatch("INSERT INTO t2 VALUES (1, 0)"); deadlockStmt.addBatch("INSERT INTO t2 VALUES (2, 0)"); deadlockStmt.addBatch("UPDATE t1 SET x=2 WHERE id=0"); deadlockStmt.executeBatch(); } catch (SQLException sqlEx) { sqlEx.printStackTrace(); } } }.run(); The part right after that executes (as can be seen in log): this.stmt.executeUpdate("INSERT INTO t1 VALUES (0, 0)");
[18 Jun 2010 14:18]
Mark Matthews
There's definitely something strange going on here. On my machine (Mac OS/X SL), the current 5.5 release hangs indefinitely on this test.
[18 Jun 2010 14:24]
Tonci Grgin
Whatever it is it's not repeatable on *proper* box :-) Joke aside, Eric, please attach server error log if not complete crash dump... Without that we can not proceed.
[18 Jun 2010 16:22]
MySQL Verification Team
I tried 5.5.3 x64 + c/j 5.1.3 rev 945 on windows as Eric suggested. But the testsuite gets to a point then appears to hang, and the reason is this: | Sleep | 747 | | NULL | | Sleep | 745 | | NULL | | Sleep | 745 | | NULL | | Sleep | 743 | | NULL | | Sleep | 739 | | NULL | | Query | 688 | Waiting for table | DROP TABLE IF EXISTS t1 | | Sleep | 688 | | NULL | Some other transaction holds locks on the table t1, so we observe expected waiting: ---TRANSACTION 4173, not started, OS thread id 1804 MySQL thread id 137, query id 3444 127.0.0.1 root Waiting for table DROP TABLE IF EXISTS t1 ---TRANSACTION 4174, ACTIVE 829 sec, OS thread id 2576 5 lock struct(s), heap size 1216, 5 row lock(s), undo log entries 3 MySQL thread id 138, query id 3441 127.0.0.1 root This looks like a bug in the tests. There's no evidence of server crash here. If manually ran "kill 138" the testsuite continues.
[18 Jun 2010 17:44]
Mark Matthews
Shane, I see the issue now, at least with the testsuite (and have fixed the semantics so that the test will at least pass). However, I've also seen that the testsuite will stay lodged in this state essentially forever, and even when terminating the application, the two deadlocked connections will remain this way, essentially forever until human intervention, well...intervenes and KILLs one or the other. Does the MDL code do no deadlock detection, or timeout? Or is it supposed to, and it's just broken?
[18 Jun 2010 18:11]
MySQL Verification Team
Works after specifying "lock-wait-timeout=55" in my.ini the testsuite finished but failed testBug39956 "The used table type doesn't support AUTO_INCREMENT...." http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_lock_wait_timeo... Maybe the testsuite should set this variable dynamically on >=5.5.3 and deal with the error??
[28 Jun 2010 13:41]
Tonci Grgin
Guys, could it be engine-related? I see no reference to engine used. I did test on MyISAM, all went fine.
[18 Jul 2010 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[23 Aug 2010 8:41]
Tonci Grgin
Eric?
[23 Sep 2010 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".