| Bug #59908 | gis regression test fails on PPC64 | ||
|---|---|---|---|
| Submitted: | 2 Feb 2011 22:52 | Modified: | 28 Mar 2011 18:04 |
| Reporter: | [ name withheld ] | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 5.5.8 | OS: | Linux (Fedora, RHEL-6) |
| Assigned to: | CPU Architecture: | Any | |
[3 Feb 2011 15:38]
[ name withheld ]
Upon further investigation, the -ffloat-store hack only fixes it with some versions of gcc (not so surprising as all that). It did work for me with the current RHEL-6 gcc (4.4.4 or 4.4.5) but it turns out it still fails with gcc 4.6.0 --- see https://bugzilla.redhat.com/show_bug.cgi?id=674253 So I guess I'll be disabling the gis regression test, instead, until something gets done about this.
[4 Feb 2011 16:20]
MySQL Verification Team
I couldn't repeat on Fedora 14 X86_64 and current source tree: 110204 13:31:40 [Note] bin/mysqld: ready for connections. Version: '5.5.10-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution 110204 13:54:45 InnoDB: Assertion failure in thread 140125460879104 in file /home/miguel/bzr/5.5/storage/innobase/row/row0sel.c line 3698 InnoDB: Failing assertion: trx->conc_state == 0 || trx->conc_state == 1 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
[4 Feb 2011 16:29]
[ name withheld ]
No, of course you can't repeat it on x86_64. The point is that the regression test's expected outputs are specific to Intel platforms and can't reliably be reproduced elsewhere.
[4 Feb 2011 16:44]
MySQL Verification Team
Sorry back to open, didn't see PPC64 specif.
[26 Mar 2011 2:06]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior with version 5.5.10. Please try with this version in your environment and inform us if bug still exists.
[28 Mar 2011 17:50]
[ name withheld ]
Hmm ... 5.5.10 appears to pass this regression test on both PPC64 and S390X (tested on RHEL-6). I see that it's still expecting seventeen digits of precision, though, which seems unlikely to be portable to anything with even slightly non-IEEE arithmetic.
[28 Mar 2011 18:04]
Sveta Smirnova
Thank you for the update. Closing as "Can't repeat"
Description: The gis regression test fails like this when mysql 5.5.8 is built on PPC64 using RHEL-6 or Fedora rawhide: main.gis [ fail ] Test ended at 2011-01-31 17:32:06 CURRENT_TEST: main.gis --- /builddir/build/BUILD/mysql-5.5.8/mysql-test/r/gis.result 2010-12-03 20:58:24.000000000 +0300 +++ /builddir/build/BUILD/mysql-5.5.8/mysql-test/r/gis.reject 2011-01-31 20:32:05.883410687 +0300 @@ -655,7 +655,7 @@ select object_id, geometrytype(geo), ISSIMPLE(GEO), ASTEXT(centroid(geo)) from t1 where object_id=85984; object_id geometrytype(geo) ISSIMPLE(GEO) ASTEXT(centroid(geo)) -85984 MULTIPOLYGON 0 POINT(-114.87787186923313 36.33101763469059) +85984 MULTIPOLYGON 0 POINT(-114.87787186923326 36.33101763469053) drop table t1; create table t1 (fl geometry not null); insert into t1 values (1); mysqltest: Result content mismatch I see a number of related reports in your archives, such as bug #52208, but the fix applied for that evidently didn't fix this. How to repeat: Run standard regression tests. Suggested fix: I've been able to work around it by adding -ffloat-store to CFLAGS, but this solution is probably costly in performance, not to mention that I don't have any great confidence in it holding up over time. My opinion is that it's simply insane to expect to get 17 reproducible digits out of float8 math, and that the only solution that's going to work over the long term is to modify the regression tests to not expect more than 14 or so reproducible digits.