Bug #36041 mysql-test-run doesn't seem to string match 100% effectively on Windows
Submitted: 13 Apr 2008 19:18 Modified: 6 May 2008 18:40
Reporter: Patrick Crews Email Updates:
Status: Closed Impact on me:
None 
Category:Tests: Server Severity:S3 (Non-critical)
Version:5.1 OS:Windows
Assigned to: Georgi Kodinov CPU Architecture:Any
Tags: mysql-test-run, Tests, windows

[13 Apr 2008 19:18] Patrick Crews
Description:
mysql-test-run seems to be having problems with string matching on Windows.

--replace_result seems to be failing when evaluating path-oriented variables like $MASTER_MYSOCK, $MYISAMPACK, etc.  (See Bug#36026 as an example).  --eval'ing the variable and comparing it to the value returned in a result show no discernable differences

Also, certain tests (See Bug#36036 as an example) are producing what appear to be identical expected and actual results, but are failing -- creating file_1 and file_2 from the mysql-test-run output and running diff on them detects 0 differences.

It is not known if these two issues are related, but as they are both related to string matching and occurring only on Windows systems, I am thinking they are somehow related.

How to repeat:
For the --replace result issue, run funcs_1.myisam_trig03 on a Windows system

From the mysql-test directory, execute the following command and observe the failure output -- the replace command didn't affect the actual results

./mysql-test-run.pl --suite=funcs_1 myisam_trig03

For the result matching issue, run parts.partition_engine_myisam

From the mysql-test directory, execute the following command and observe the failure output -- no visible difference between expected and actual results

./mysql-test-run.pl --suite=parts partition_engine_myisam

Suggested fix:
Need to determine how mysql-test-run is interpreting these strings to understand why a proper match isn't being detected in either case.

This could just be an issue with Windows and we might try adding character set restrictions to the tests to try to guarantee good matches (have not taken the time to try this course of action)
[15 Apr 2008 14:16] Patrick Crews
Update to the bug:

1)  We can disregard the identical test results issue.  Further investigation has shown that this is a case of '\n' vs. '\r' for line terminators.  Will adjust the offending tests to correct this problem.

2)  The path issue is still present.  While a patch for another bug corrected the failing tests that first brought this to light, --replace_result still fails when a path is involved.

As an example, put the following into a .test file, run ./mysql-test-run.pl --record <test_name> and observe the results on a Windows System:

--echo $MYISAMPACK
--replace_result $MYISAMPACK myisampack_new_val
--exec $MYISAMPACK -V

This should result in myisampack_new_val Ver <number> for <system> on <architecture>
Currently it returns <full_path_to_myisampack.exe> Ver <number> for <system> on <architecture>

Suspect that this is due to the difference in Windows path separator / vs \.
[29 Apr 2008 16:09] Bugs System
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/46197

ChangeSet@1.2572, 2008-04-29 19:08:52+03:00, gkodinov@magare.gmz +3 -0
  Bug #36041: mysql-test-run doesn't seem to string match 
    100% effectively on Windows
  
  The mysqltest docs state that the 'replace_result' command
  doesn't perform any escape processing.
  However the current implementation was processing backslash 
  escapes in the from/to strings.
  This prevents replacing e.g. patch on windows (where backslash
  is used as a path separator).
  Fixed by removing the backslash escape processing from 
  'replace_result'.
[30 Apr 2008 16:59] Patrick Crews
Ok to push.
[6 May 2008 0:29] Bugs System
Pushed into 5.1.25-rc
[6 May 2008 0:32] Bugs System
Pushed into 6.0.6-alpha
[6 May 2008 18:40] Paul DuBois
Noted in 5.1.25, 6.0.6 changelogs.

mysqltest was performing escape processing for the --replace_result
command, which it should not have been.