qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Arno Wagner <645662@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 645662] Re: Python 3.1.2 math errors with Qemu 0.12.5
Date: Mon, 25 Oct 2010 02:25:00 -0000	[thread overview]
Message-ID: <20101025022500.5028.79156.malone@palladium.canonical.com> (raw)
In-Reply-To: 20100923002702.20683.97345.malonedeb@soybean.canonical.com

And I unexpectedly had more time to dig.

Findings:

  - asinh() is not in IEEE754, please ignore my comment about
    non-conformity, sorry.
  - The calculation for asinh() is pretty badly conditioned, i.e.
    it blows up errors in the basic calculations.
  - asinh() is implemented in glibc in assembler on the FPU stack.   
    This would mean 80 bits float representation.

Error observations:

  Calculations for asinh( -2.1073424255447017e-08), derived from
  the Python 3.1.2 selftest. Formula is asinh(x) = log(x+sqrt(x*x+1))
  Reference is a calculation with long double (128 bit)

  - qemu:           6 correct digits behind the dot
  - C with double:  7 correct digits behind the dot
  - i387:          10 correct digits behind the dot

Possible root cause:

   The observed error may be due to qemu using 64 bit double math in
   the FPU implementation, instead of the 80 bit internal precision   
   a real i387 uses.

Comparison with kernel i387 emulation

   As an additional verification, I tried the calculations using the
   Linux kernel coprocessor emulation. This basically failed. With
   kernel 2_6_26 and 2_6_27 and the ''no387'' flag, the kernel locked
   up without output early during boot. With 2.6.34, I could not do
   an ssh login. I may try this again later, and especially try
   to find out what is wrong with qemu and 2.6.34.

Consequences:

  1) qemu is significantly less accurate for some mathematics than a
     genuine i387. This may cause problesm with sensitive mathematics
     developed on a real i387.
  2) qemu can be fingerprinted easily using this problem. This may
     have security implications.

Fix Options:

  1) - Moving the FPU internal representation to long double. It will
       still not be the same results as on an  i387, but it will be
       _more_ accurate instead of less, which generally is far less
       of a problem.

       Pro:  Higher accuracy
       Cons: Slower

     - Use code derived from the Linux kernel i387 FPU emulator.
       The emulator is not bit-exact, but relatively close and it
       is used at least on some small x86 architectures.

       Pro:  Higher accuracy
       Cons: Need to integrate foreign code

     - Leave it as it is but add a clear warning to the "Known qemu
       Problems" Section in the manual and Wiki (I did not find one, I
       think it should be added in an easily findable place), that
       i387 FPU emulation is only 64 bits internally and may be less
       exact for combined calculations done on the FPU stack, such
       as asinh() in glibc(), than a real i387.

       You may recommend to use kernel FPU emulation, but
       this may not work or be a pain to get working.

       Pro: Least work
       Cons: Not really a solution 

2) Fixing this is difficult and there are other ways to find
     out that you are running in qemu anyways. I think the security
     implications are insiginficant in most cases.

-- 
Python 3.1.2 math errors with Qemu 0.12.5
https://bugs.launchpad.net/bugs/645662
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)),
gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu,
3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources
on Debian Lenny with kernel  2.6.34.6 from kernel.org, gcc  (Debian 4.3.2-1.1) 4.3. 

Regression testing errors:

test_cmath
test test_cmath failed -- Traceback (most recent call last):
  File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in
    self.fail(error_message)
AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0))
Expected: complex(3.141592653589793, -2.1073424255447014e-08)
Received: complex(3.141592653589793, -2.1073424338879928e-08)
Received value insufficiently close to expected value.


test_float
test test_float failed -- Traceback (most recent call last):
  File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in
    self.assertEqual(s, repr(float(s)))
AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25'


test_math
test test_math failed -- multiple errors occurred; run in verbose mode for deta

=>

runtests.sh -v test_math

le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math
test_math BAD
 1 BAD
 0 GOOD
 0 SKIPPED
 1 total
le01:~/tools/python3/Python-3.1.2#

  parent reply	other threads:[~2010-10-25  2:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-23  0:27 [Qemu-devel] [Bug 645662] [NEW] Python 3.1.2 math errors with Qemu 0.12.5 Arno Wagner
2010-10-23 14:44 ` [Qemu-devel] [Bug 645662] " Arno Wagner
2010-10-23 14:45 ` Arno Wagner
2010-10-25  2:25 ` Arno Wagner [this message]
2017-01-19  8:34 ` Thomas Huth
2017-01-19 15:17   ` Arno Wagner
2017-01-23 21:20 ` Thomas Huth
2017-01-23 22:56   ` Arno Wagner
2017-11-29 11:19 ` Peter Maydell
2017-11-29 12:31 ` [Qemu-devel] [Bug 645662] Re: QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit Thomas Huth
2017-11-29 16:33 ` Arno Wagner
2019-08-16  5:47 ` Thomas Huth
2019-08-16 13:08   ` Arno Wagner
2019-08-16 14:06 ` Peter Maydell
2019-08-16 16:46   ` Arno Wagner
2020-11-21 23:21 ` Peter Maydell
2020-11-22 16:41   ` Arno Wagner
2020-11-24 16:57 ` Richard Henderson
2021-05-03  9:28 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101025022500.5028.79156.malone@palladium.canonical.com \
    --to=645662@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).