MySQL Bugs: #20676: Sporadic failure of test case 'events

Bug #20676	Sporadic failure of test case 'events_stress'
Submitted:	24 Jun 2006 17:09
Reporter:	Kristian Nielsen	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Stored Routines	Severity:	S2 (Serious)
Version:	5.1.12	OS:	Linux (Linux)
Assigned to:	Kristian Nielsen	CPU Architecture:	Any

Description:
The test case events_stress randomly causes the test suite to fail.

The failures occur because of lines like these in var/log/master.err, which causes the mysql-test-run.pl program to fail the test suite:

Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock
Warning: found too many locks at write_wait: enter write_lock

The problem does not show up in every run, but it can be repeated reliably by running the test case in a loop until it fails.

How to repeat:
(cd mysql-test && for i in `seq 1 300`; do echo XXX $i XXX; MTR_BUILD_THREAD=4 perl mysql-test-run.pl --tmpdir=/dev/shm/t4 --vardir=/dev/shm/v4 --timer --ps-protocol --mysqld=--binlog-format=row events_stress || exit 1; done)

It varies how many iterations are necessary before the problem triggers (I have
seen as many as 30 or more needed), but it always fails sooner or later.

Hm, I think I know what the problem is here.

The test case seems to create 250 simultaneous events that all do

    INSERT INTO events_test.fill_it

Nothing wrong with that ... except that in mysys/thr_lock.c we have this:

    #define MAX_LOCKS   100

which cases it to put those warnings into the logfile when there are more than 100 waiters for a table, as there may easily be with 250 concurrent events.

So should be simple to solve, pick one of these two options:

1. Reduce the number of events to 5*20 = 100 in the test case.

2. Increate the constant in thr_lock.c to 250.

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

After discussion with Andrew, I modified the test to use different tables for different events classes. This avoids the only-100-waiters limitation.

Pushed to 5.1.12.

This is just a test suite failure, no user-visible bug. No documentation nedded.