MySQL Bugs: #35503: falcon_bug_34351_C.test times out on Pushbuild

Bug #35503	falcon_bug_34351_C.test times out on Pushbuild
Submitted:	22 Mar 2008 19:19	Modified:	13 Dec 2008 7:22
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0, 6.0-falcon-team	OS:	Any
Assigned to:	John Embretsen	CPU Architecture:	Any
Tags:	F_TEST, pb2, pushbuild, test failure

Description:
falcon_bug_34351_C.test times out on Pushbuild.

How to repeat:
To reproduce run falcon_bug_34351_C.test several times until you see a deadlock which leads to test timeout.

Thank you for the report.

Verified as described.

I don't see a deadlock anymore but a steady memory usage. See Bug#39711 for details.

See memory leak issue in Bug#39711 instead.

Re-opening this bug, as the test still times out, but (it seems) only on Freebsd7 platforms in Pushbuild 2 (PB2). These platforms are not used in Pushbuild 1, nor in team-level branches hooked to PB2.

Fails in mysql-6.0 branch, example:

http://clustra.norway.sun.com/~bteam/pb2/web.py?template=push_details&push=99607
(test-max-freebsd7-x86, test-max-freebsd7-x86_64)

John,  Both 34351_A and 34351_C could probably be cut in half, from a while loop of 10000 to 5000.  If you want, you could make -big versions as well with a loop of maybe 20000.  These tests used to get update conflicts given the right timing.

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/59411

2916 John H. Embretsen	2008-11-20
      Fix for Bug#35503 - falcon_bug_34351_C.test times out on Pushbuild.
      Reducing loop count inside procedure from 10k to 5k in both falcon_bug_34351_A
      and falcon_bug_34251_C, as per Kevin Lewis' recommendations.
      Test case running time is effectively cut in half by doing this.
      
      Also adding new -big versions of those tests, running 20k iterations, in case 
      the bug is not triggered by 5k iterations in the non-big version. 
      These tests need to be run using the --big-test option of mysql-test-run.pl.
      On slower machines one might have to increase the test case timeout as well,
      e.g. --testcase-timeout=30 for a timeout of 30 minutes.

Running times for all affected test cases on a test host running RHEL 5, 4x2800 MHz CPU, background load, given the patch described at http://lists.mysql.com/commits/59411:

TEST                           RESULT         TIME (ms)  TIME (approx. min)
---------------------------------------------------------------------------

falcon.falcon_bug_34351_A-big  [ pass ]         506750   8.5
falcon.falcon_bug_34351_A      [ pass ]         125638   2
falcon.falcon_bug_34351_C-big  [ pass ]        1012260   17
falcon.falcon_bug_34351_C      [ pass ]         254212   4+

If test running time increases, it could possibly be related to bug#36700 (Running falcon_bug_28048 shows increasing memory usage and run time)...

Actually, running time for non-big tests (34351 A and C) is less than 30 seconds on the linux host mentioned above when there is no background load. Should be relatively safe for current Pushbuild hosts.

Note on the previous note: Smallish running times (< half minute) were measured using the --mem mysqltest option. No --mem still results in about the same results as reported earlier.

Patch pushed to mysql-6.0-falcon-team branch on 2008-11-25 13:44:28 GMT.

See Bug#39711 (Running falcon_bug_34351_C shows increasing memory usage) for further investigations regarding running time and memory usage related to falcon_bug_34351_C.test.

Pushed into 6.0.9-alpha  (revid:john.embretsen@sun.com-20081120155823-v4dqfzqlkjqa6y5r) (version source revid:hky@sun.com-20081127084516-nbu7693932vcz2st) (pib:5)

No documentation needed.