Description:
One of the changes of 5.1.40 over 5.1.39 is the "debug_sync" feature.
The test checking it fails on one platform only:
OS X 10.4, PowerPC 64 bit.
It passes on all other platforms, including PowerPC-64 with OS X 10.5 or with AIX 5.3, PowerPC-32 with all OSes, and other big-endian CPUs.
This is the symptom:
=====
main.debug_sync [ retry-fail ] timeout after 900 seconds
Test ended at YYYY-MM-DD HH:MM:SS
Test case timeout after 900 seconds
== /PATH/mysql-test/var/log/debug_sync.log ==
ERROR 42000: Missing valid number after EXECUTE
SET DEBUG_SYNC='p0 WAIT_FOR s2 TIMEOUT 7 EXECUTE 2 HIT_LIMIT 0x3';
ERROR 42000: Missing valid number after HIT_LIMIT
SET DEBUG_SYNC= 7;
ERROR 42000: Incorrect argument type to variable 'debug_sync'
SET GLOBAL DEBUG_SYNC= 'p0 CLEAR';
ERROR HY000: Variable 'debug_sync' is a SESSION variable and can't be used with SET GLOBAL
SET @myvar= 'now SIGNAL from_myvar';
SET DEBUG_SYNC= @myvar;
SHOW VARIABLES LIKE 'DEBUG_SYNC';
Variable_name Value
debug_sync ON - current signal: 'from_myvar'
SET DEBUG_SYNC= LEFT('now SIGNAL from_function_cut_here', 24);
SHOW VARIABLES LIKE 'DEBUG_SYNC';
Variable_name Value
debug_sync ON - current signal: 'from_function'
SET DEBUG_SYNC= 'now SIGNAL something';
SHOW VARIABLES LIKE 'DEBUG_SYNC';
Variable_name Value
debug_sync ON - current signal: 'something'
== /PATH/mysql-test/var/tmp/analyze-timeout-mysqld.1.err ==
mysqltest: Could not open connection 'default' after 500 attempts: 2002 Can't connect to local MySQL server th
rough socket '/PATH/mysqld.1.sock' (61)
- saving '/PATH/mysql-test/var/log/main.debug_sync/' to '/PATH/mysql-test/var/log/main.debug_sync/'
=====
How to repeat:
Found while running the test suite.
Suggested fix:
Not known.
At first I hoped it might be related to bug#39749, but this seems to contradict the fact that the test passes on other Power-64 platforms.
Ingo suspects it might be a problem in "debug_sync.cc":
"set_timespec(abstime, action->timeout);" might set a time which doesn't let "pthread_cond_timedwait()" wake up immediately, which might be solved by checking the "timeout" value and avoid entering the loop around "pthread_cond_timedwait()".
There haven't been any checks with that yet.