| Bug #36025 | funcs_1.<engine>_storedproc Test failing on Windows | ||
|---|---|---|---|
| Submitted: | 13 Apr 2008 14:58 | Modified: | 23 Jan 2009 10:38 |
| Reporter: | Patrick Crews | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 5.1 | OS: | Other (Windows, Solaris on x86) |
| Assigned to: | Alexey Botchkov | CPU Architecture: | Any |
| Tags: | funcs_1, StoredProc, Tests, windows | ||
[13 Apr 2008 14:58]
Patrick Crews
[25 Apr 2008 0:19]
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/45979 ChangeSet@1.2589, 2008-04-24 20:18:32-04:00, pcrews@pcrews-mac-local.local +1 -0 Bug#36025 - funcs_1.<engine>_storedproc Test failing on Windows Adding change to CMakeLists.txt to make sure floating points will behave properly on Windows builds made with VS2003
[12 May 2008 6:08]
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/46612 ChangeSet@1.2582, 2008-05-12 09:58:57+05:00, holyfoot@mysql.com +4 -0 Bug #36025 func_1.<engine>_storedproc test failing on Windows. Float types are of limited precision (15 digits for DOUBLE for example), so if the string representation has more than 15 digits, the precision of the initial string will be lost. Which is worse, different sprintf() versions can produce slightly different result on these data (what caused this bug). As we implement homegrovn double->string conversion in 6.0, this bug will disappear there. Still i'd propose this patch. Here we store the initial string representation of a 'float' value and use it to produce decimal if it's necessary. That way, we won't lost the precision up to 60 digits.
[22 Aug 2008 16:39]
Daniel Fischer
I can reproduce this on Solaris 10 x86, however the result seems to have even more differences that might or might not be related to rounding differences. Specifically: -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 Full output for one of the *_storedproc tests follows: funcs_1.innodb_storedproc [ fail ] --- /export/home/pb2/test/sourcebuilder-build-4855-1219372712.97/mysql-5.1.28-solaris10-i386-test/mysql-test/suite/funcs_1/r/innodb_storedproc.result Thu Aug 21 22:04:12 2008 +++ /export/home/pb2/test/sourcebuilder-build-4855-1219372712.97/mysql-5.1.28-solaris10-i386-test/mysql-test/suite/funcs_1/r/innodb_storedproc.reject Fri Aug 22 14:08:07 2008 @@ -1111,8 +1111,6 @@ CALL sp1( 0.1234567890987654321e-6 ); @v1 0.000000123456789098765400000000 -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 CALL sp1( 0.1234567890987654321e+5 ); @v1 12345.678909876540000000000000000000 @@ -1130,7 +1128,7 @@ Note 1265 Data truncated for column 'f1' at row 1 CALL sp1( 0.1234567890987654321e-4 ); @v1 -0.000012345678909876550000000000 +0.000012345678909876540000000000 Warnings: Note 1265 Data truncated for column 'f1' at row 1 CALL sp1( 0.1234567890987654321e+3 ); @@ -18006,8 +18004,6 @@ CALL sp70_n(-1e+40); f1 -10000000000000000000000000000000000000000 -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 CALL sp70_n( -10000000000000000000000000000000000000000 ); f1 -10000000000000000000000000000000000000000 @@ -18020,8 +18016,6 @@ CALL sp71_nu(1.00e+40); f1 10000000000000000000000000000000000000000 -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 CALL sp71_nu( 10000000000000000000000000000000000000000 ); f1 10000000000000000000000000000000000000000 @@ -18034,8 +18028,6 @@ CALL sp72_nuz(1.00e+40); f1 0000000000000000000000010000000000000000000000000000000000000000 -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 CALL sp72_nuz( 10000000000000000000000000000000000000000 ); f1 0000000000000000000000010000000000000000000000000000000000000000 @@ -18048,8 +18040,6 @@ CALL sp73_n_z(1.00e+40); f1 0000000000000000000000010000000000000000000000000000000000000000 -Warnings: -Note 1265 Data truncated for column 'f1' at row 1 CALL sp73_n_z( 10000000000000000000000000000000000000000 ); f1 0000000000000000000000010000000000000000000000000000000000000000 mysqltest: Result content mismatch Stopping All Servers Restoring snapshot of databases Resuming Tests
[22 Jan 2009 21:16]
Matthias Leich
Hi Alexey,
some notes:
1. During a big cleanup I replaced the engine variants
of the storedproc test by a modified non engine
specific test
mysql-test/suite/funcs_1/t/storedproc.test .
2. There is now a routine
suite/funcs_1/storedproc/param_check.inc
which covers the stored procedure + numerics related checks.
The philosophy is now:
The final (after assignment) content of @v1_proc and
@v1_func should be as good/accurate/damaged as the content
of a column f1 with data type DECIMAL(60,30).
Therefore the successor mysql-test/suite/funcs_1/t/storedproc.test
does no more suffer from the assumption that we get on every
OS etc. the same numeric results.
So the future of this bug just depends on your opinion.
If you say the current bug is
a) a bug within the test and the server is allowed to
show slightly different values depending on the OS etc.
than the current bug is fixed by my changes several
months ago
b) within the server = the slightly different values depending
on the OS/math lib etc. must not exist than the current bug
- needs new replay scripts
- is a server bug and no test bug
- disappears most probably somewhere in future
(maybe we have it already?) with a homegrown
double->string conversion implementation.
I vote for a).
Regards
Matthias
[23 Jan 2009 10:37]
Matthias Leich
- This bug was a valid bug within the test scripts till ~ August 2008. - A massive change within the test removed a lot of the differences.around September 2008. - The fix for Bug#40177 Test funcs_1.storedproc failing on Pushbuild pushed to 5.1, 6.0 main trees January 2009 should have removed the remaining result set differences. Therefore I set the bug now to "Can't repeat".
