Spun off of bug 401781 - I'd written a test for binary streams. The test detected a strange bustage on Linux machines, SeaMonkey and Firefox. Reproducing the bug is difficult according to bz... Steps to reproduce: (1) Uncomment these marked lines: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/tests/unit/test_streams.js&rev=1.4&mark=89-90,119,138#89 (2) make check
What does this impact? Before we'll plus this, we need to know what this is used for, what it breaks, etc.
http://lxr.mozilla.org/seamonkey/search?string=readDouble http://lxr.mozilla.org/seamonkey/search?string=writeDouble I can't find any evidence readDouble and writeDouble are being used by anyone other than test code. I requested blocking1.9 based on the informal conversation on 11/13 in #developers about this issue.
Couldn't reproduce on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111501 Minefield/3.0b2pre - Fedora 7. I would imagine that's not too different from the reference platform: http://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0
-'ing. If we can determine what uses readDouble and writeDouble and it's an issue, please re-nom.
Flags: blocking1.9? → blocking1.9-
qawanted: can anyone reproduce this? (Note bug 403992, which is to try getting access to a tinderbox clone.)
I can reproduce. This is related to bug 408258 comment 4: Using -fstrict-aliasing (enabled at -O2) breaks nsBinaryOutputStream::writeDouble() here and nsBinaryOutputStream::writeFloat() in bug 409881 (x86_64). I noticed that adding a printf() call in the beginning of nsBinaryOutputStream::writeDouble or nsBinaryOutputStream::writeFloat fixes the problem, too.
I would humbly suggest removing readDouble, writeDouble. Again, no one is currently using them in the Mozilla code base, and they have known test failures.
note that something like bug 408258 comment 7 could fix the issue.
You need to log in before you can comment on or make changes to this bug.