Context Navigation

← Previous Ticket
Next Ticket →

#31537 closed defect (bug) (fixed)

Database lock timeout in phpunit (fresh install)

Reported by:	byron.hawkins	Owned by:
Priority:	normal	Milestone:	4.1.2
Component:	Build/Test Tools	Version:	4.2
Severity:	normal	Keywords:	fixed-major
Cc:		Focuses:

Description

After following the instructions, most of the tests fail with "lock timeout" errors in the database. I tried versions 4.1 (revision 30975), 4.1.1 (revision 31478) and the latest (revision 31602), testing against the included ./src/ directory.

I have MySQL configured to allow 30,000 connection with a timeout of 500 seconds, and my Ubuntu 14.04 server has 16GB RAM completely available for the tests. There is minimal load on the database while the tests are executing, so the problem is caused by some kind of direct conflict on the wptests_options table. Here is a sample of the errors:

WordPress database error Lock wait timeout exceeded; try restarting transaction for query 
UPDATE `wptests_options` SET `option_value` = '1' WHERE `option_name` = 'comments_per_page' 
made by PHPUnit_TextUI_Command::main, PHPUnit_TextUI_Command->run, PHPUnit_TextUI_TestRunner->doRun, 
PHPUnit_Framework_TestSuite->run, PHPUnit_Framework_TestSuite->run, PHPUnit_Framework_TestCase->run, 
PHPUnit_Framework_TestResult->run, PHPUnit_Framework_TestCase->runBare, 
Tests_Comment_GetCommentsPagesCount->tearDown, update_option

If this problem is caused by an unmet configuration dependency, then that requirement needs to be stated plainly on the instruction page for the automated tests. Users should be able to simply download and run the tests, without having to figure out the required configuration.

Change History (13)

#1 @boonebgorges
12 years ago

Milestone Awaiting Review → 4.2

Thanks for the report. The problem is not unmet dependencies. It's a bug in the tests.

Test classes that have their own tearDown() method must run parent::tearDown() last - or at least after they've done all db-related cleanup. Otherwise they run it outside the scope of the MySQL transaction, which causes lock issues in some cases. I'm not sure why it only comes up in some situations - I'm guessing there is some config that's causing my rig (and most people's rigs) to ignore the problem.

#2 @boonebgorges
12 years ago

In 31622:

In PHPUnit test classes, parent::tearDown() should be the last thing done in tearDown() methods.

WP_UnitTestCase::tearDown() restores the test environment to the default
conditions, including rolling back the MySQL transaction that the test takes
place in, resetting globals, and unhooking test-specific filters. As such, all
teardown routines for specific tests should happen before the parent class's
tearDown() method is called. Failure to do so can cause database locks on
certain configurations, among other problems.

See #31537.

#3 @boonebgorges
12 years ago

byron.hawkins - Could you try updating your trunk installation and running the tests again? After [31622] you should find that the database locks have gone away. Thanks.