curl corrupts floating point context

Status changed to 'Confirmed' because the bug affects multiple users.

I have the same problem. Plain install of Ubuntu 10.04 server 32 bit.

apt-get install python-software-properties
OK

apt-add-repository ppa:zfs-native/stable
...

Press [ENTER] to continue or ctrl-c to cancel adding it

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py", line 99, in run
    self.add_ppa_signing_key(self.ppa_path)
  File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py", line 132, in add_ppa_signing_key
    tmp_keyring_dir = tempfile.mkdtemp()
  File "/usr/lib/python2.7/tempfile.py", line 322, in mkdtemp
    name = names.next()
  File "/usr/lib/python2.7/tempfile.py", line 141, in next
    letters = [choose(c) for dummy in "123456"]
  File "/usr/lib/python2.7/random.py", line 274, in choice
    return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty
ValueError: cannot convert float NaN to integer

The file /etc/apt/sources.list.d/zfs-native-stable-precise.list is there then, but I think keys are not setup correctly, I got signing alerts when installing software from that ppa.

The version that showed this problem is 0.82.7.3

A workaround that worked for me is downgrading python-software-properties to version 0.82.7 by performing

apt-get install python-software-properties=0.82.7

Adding "apt-add-repository" to the title so this bug report is easier to find. (I searched for apt-add-repository bugs and this was not in the list.)

What hardware are you seeing the problem on? I'm wondering if this might be a CPU capability dependent bug because I don't get the error on a new Ubuntu Server 12.04.1 32bit installation in a VM on a VMWare ESXi 4.1 host running on a PowerEdge R710 with dual Xeon L5520 CPUs. I do get the problem with an Identical version of Ubuntu freshly installed and updated on an older Compaq DL380 server that has dual PIII 1.4 GHz CPUs.

The workaround mentioned in #4 worked for me.

I've tried adding the same repository on two different PCs both running 12.04.2, but only the one with a AMD Sempron 2600+ CPU had the bug. The other PC has a Core i3 CPU.

Confirm bug for trying to add ppa:webupd8team/y-ppa-manager and ppa:webupd8team/java, and #4's workaround working, on a machine running 12.04 with an AMD Athlon

ian@Athlon:~$ lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Vendor ID: AuthenticAMD
CPU family: 6
Model: 8
Stepping: 1
CPU MHz: 2100.132
BogoMIPS: 4200.26
L1d cache: 64K
L1i cache: 64K
L2 cache: 256K

I haven't come across this problem on two other PCs, one with a Intel Core2, the other with an Intel Atom, running 12.10.

The significant change between python-software-properties 0.82.7 and 0.82.7.3 is in the .3 release: "softwareproperties/ppa.py: download gpg key to temporary keyring, and validate using v4 fingerprint before importing to apt keyring." (Specifically, that change is the reason that tempfile.mkdtemp() is called in the later version of the package.)

However, this doesn't seem to be a bug in the python-software-properties code itself, but rather some strange interaction between the "pycurl" module (used directly by ppa.py) and the "random" module (used by the tempdir module).

That is, I'm able to reproduce the problem in an interactive python session, without using any software-properties .py files:

==========================
$ uname -a
Linux pincup 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013 i686 athlon i386 GNU/Linux

$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import pycurl, tempfile
>>> def geturl(url):
... curl=pycurl.Curl()
... curl.setopt(pycurl.URL,url)
... curl.perform()
... print
... print "before:", tempfile.mkdtemp()
... curl.close()
... print "after:", tempfile.mkdtemp()
...
>>> geturl("http://launchpad.net/api/")
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://launchpad.net/api/">here</a>.</p>
<hr>
<address>Apache/2.2.14 (Ubuntu) Server at launchpad.net Port 80</address>
</body></html>

before: /tmp/tmpuXD_at
after: /tmp/tmpon2PEe

>>> geturl("https://launchpad.net/api/")
Object: <lp.services.webapp.servers.WebServiceClientRequest instance URL=https://launchpad.net>, name: ''
before: /tmp/tmpGMMoKM
after:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in geturl
  File "/usr/lib/python2.7/tempfile.py", line 322, in mkdtemp
    name = names.next()
  File "/usr/lib/python2.7/tempfile.py", line 141, in next
    letters = [choose(c) for dummy in "123456"]
  File "/usr/lib/python2.7/random.py", line 274, in choice
    return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty
ValueError: cannot convert float NaN to integer
>>> tempfile.mkdtemp()
'/tmp/tmpCoJDyZ'
==========================

So, it seems to be triggered by the curl.close() call, but only after an https: URL has been accessed. Also, note that the ValueError happens only one time; the next call to mkdtemp() works normally again.

Actually, it looks like the problem is in pycurl, since calling .close() seems to cause the very next floating point operation to return NaN. (In the case of add-apt-repository, that floating point operation just happens to be in the random() call invoked from inside the tempfile.mkdtemp() function.)

==========================
~$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pycurl, tempfile
>>> def geturl(url):
... curl=pycurl.Curl()
... curl.setopt(pycurl.URL,url)
... curl.perform()
... print
... print "before:", 1.0/2, 1.0/2
... curl.close()
... print "after:", 1.0/2, 1.0/2
... print tempfile.mkdtemp()
...
>>>
>>> geturl("https://launchpad.net/api/")
Object: <lp.services.webapp.servers.WebServiceClientRequest instance URL=https://launchpad.net>, name: ''
before: 0.5 0.5
after: nan 0.5
/tmp/tmplHPMk4
==========================

Given that performing any sort of floating-point operation seems to clear the error condition, I tried simply added a "dummy = 1.0/2" line to the get_ppa_info_from_lp() function immediately after the curl.close() line (see attached patch)... and after that add-apt-repository successfully processed the PPA key that had previously caused it to fail.

The attachment "quick-and-dirty workaround for the NaN generated by pycurl.close()" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

I can confirm this patch worked for me! I'm a n00b with using the bug tracking system, so sorry if this comment is not needed or should have included more information.

I found a Redhat bug that seems to be related:
  https://bugzilla.redha t.com/show_bug.cgi?id=758446
(It's for a different Python program, but pycurl is used there, too, and in it NaNs are similarly showing up in unexpected places.)

In comment #9, Zdeněk Pavlas suggests the problem might related to improper cleanup after the use of MMX instructions, as explained in:
http://en.wikipedia.org/wiki/SSE2#Differences_between_MMX_and_SSE2

"Once MMX has been used, the programmer must use the emms instruction (C: _mm_empty()) to restore operation to the x87 register file. [...] the corrupt floating-point state caused by failure to emit emms may go undetected for millions of instructions before ultimately causing the floating-point routine to fail, returning NaN."

I'm not sure how to verify that issue is actually what's triggering this specific problem, but the Wikipedia page goes on to mention that this cleanup is not required when SSE2 instructions are used instead of MMX, and I can confirm that the two machines I have found that exhibit this problem do have "mmx" but not "sse2" in the flags line of /proc/cpuinfo.

However, I have some other machine with that same combo of flags which don't show the bug, so it seems that the libXXX versions involved do matter. In my case, at least, the systems that do show the the bug are running Precise, and the ones that don't are running Lucid and Debian Etch.

If this "missing emms instruction" is in fact the problem, I'm also not sure exactly which library needs to be fixed (though the fact that it's https that triggers the problem might point towards libgnutls26...).

On Wed, Mar 06, 2013 at 11:18:25 -0000, Paul BROWN wrote:
> I can confirm this patch worked for me!

Cool.

I'm curious if you get the same result I do when running the direct
python test mentioned in comment #10.

Actually, here's basically the same test, but in a format easier
to cut-and-paste into your "python" session:

==========================
import pycurl
def geturl(url):
  curl=pycurl.Curl()
  curl.setopt(pycurl.URL,url)
  curl.perform()
  print
  print "before:", 1.0/2, 1.0/2
  curl.close()
  print "after:", 1.0/2, 1.0/2

geturl("https://launchpad.net/api/")
==========================

Also, what does "grep flags /proc/cpuinfo" show on your system?

      Nathan

I get:
Object: <lp.services.webapp.servers.WebServiceClientRequest instance URL=https://launchpad.net>, name: ''
before: 0.5 0.5
after: nan 0.5

with following cpu flags:
fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up

currently it affects ppa:n-muench/calibre2 and ppa:n-muench/calibre

On Thu, Mar 14, 2013 at 18:36:52 -0000, Douglas King wrote:
> currently it affects ppa:n-muench/calibre2 and ppa:n-muench/calibre

If you are experiencing the same bug as I am, you will get the same
error no matter what PPA you are trying to add. In other words, the
problem is with your local computer, not with the PPA you are trying to
use.

Do you get the "nan" output when you run the test Python code on the
machine where apt-add-repository failed?

What do
  lsb_release -a
and
  grep -E "name|flags" /proc/cpuinfo
show on that machine?

      Nathan

the hacks works for me as well

I was able to reproduce this on a 32bit Precise machine but not a 64bit Raring machine. I'm building out a 32bit Raring machine now to see if it's still reproducible.

Yes, 32bit Raring has this problem, 64bit does not apparently.

On Thu, Apr 04, 2013 at 21:06:58 -0000, Barry Warsaw wrote:
> Yes, 32bit Raring has this problem, 64bit does not apparently.

I'm curious if the machine you are using is also an MMX-but-not-SSE2
machine; what does
  grep -E "name|flags" /proc/cpuinfo
show?

Or are you saying that you found the problem with 32-bit but not 64-bit
Raring running on the same box (i.e. one with a 64-bit CPU)?

       Nathan

On Apr 04, 2013, at 10:15 PM, Nathan Stratton Treadway wrote:

>I'm curious if the machine you are using is also an MMX-but-not-SSE2
>machine; what does
> grep -E "name|flags" /proc/cpuinfo
>show?
>
>Or are you saying that you found the problem with 32-bit but not 64-bit
>Raring running on the same box (i.e. one with a 64-bit CPU)?

No, you're right. The 32bit machine is mmx-but-not-sse2.

I have a horribly ugly workaround for PyCurl in the works. I'll link a branch
when ready, but I want to get Matthias's input to see if a toolchain fix is
more appropriate.

Python 2 reproducer.

On Thu, Apr 04, 2013 at 23:14:02 -0000, Barry Warsaw wrote:
> when ready, but I want to get Matthias's input to see if a toolchain fix is
> more appropriate.

Yeah, I was wondering about that too.

It seems like the problem probably originates somewhere in libgnutls26
or below, since it's only triggered when running against an https://
URL, but when I tried to do a simple C program using the same sorts of
libcurl calls that pycurl uses, I wasn't immediately able to figure out
a way to duplicate the unexpected NaN in that context...

       Nathan

On Thu, Apr 04, 2013 at 23:14:02 -0000, Barry Warsaw wrote:
> I have a horribly ugly workaround for PyCurl in the works. I'll link a branch
> when ready, but I want to get Matthias's input to see if a toolchain fix is
> more appropriate.

(Since you have an environment set up to build the python-pycurl package
from source, it occurred to me to wonder:) How difficult would it be for
you to try building the package (without the workaround patch) against
libssl instead of libgnutls? That might be a fairly-easy way to test the
hypothesis that libgnutls is the underlying source of the problem...

       Nathan

the work around looks safe. I'm not sure that this is a toolchain issue, but maybe some other extension is involved, which uses sse math, maybe was compiled for sse?

On Fri, Apr 05, 2013 at 14:02:13 -0000, Nathan Stratton Treadway wrote:
> you to try building the package (without the workaround patch) against
> libssl instead of libgnutls? That might be a fairly-easy way to test the

(More precisely: libcurlX-openssl instead of libcurlX-gnutls.)

     Nathan

On Apr 05, 2013, at 02:24 PM, Nathan Stratton Treadway wrote:

>On Fri, Apr 05, 2013 at 14:02:13 -0000, Nathan Stratton Treadway wrote:
>> you to try building the package (without the workaround patch) against
>> libssl instead of libgnutls? That might be a fairly-easy way to test the
>
>(More precisely: libcurlX-openssl instead of libcurlX-gnutls.)

To be honest, I don't really have much more time to spend investigating this.
The workaround fixes the problem and while a bit wasteful, seems harmless
enough. Since Doko agrees, I think I'll just apply this for now, and maybe we
can re-investigate this later after Raring is released.

On Fri, Apr 05, 2013 at 15:02:54 -0000, Barry Warsaw wrote:
> To be honest, I don't really have much more time to spend investigating this.
> The workaround fixes the problem and while a bit wasteful, seems harmless
> enough. Since Doko agrees, I think I'll just apply this for now, and maybe we
> can re-investigate this later after Raring is released.

I certainly agree that further investigation can wait until after Raring
is released.

My longer-term concern with masking this at the pycurl level is that if
some library is leaving the floating-point registers in a confused
state, then it seems possible that other applications could be affected
-- perhaps in a way that's a lot more subtle than apt-add-repository's
explicit "cannot convert float NaN to integer" message...

      Nathan

On Apr 05, 2013, at 03:53 PM, Nathan Stratton Treadway wrote:

>I certainly agree that further investigation can wait until after Raring
>is released.
>
>My longer-term concern with masking this at the pycurl level is that if
>some library is leaving the floating-point registers in a confused
>state, then it seems possible that other applications could be affected
>-- perhaps in a way that's a lot more subtle than apt-add-repository's
>explicit "cannot convert float NaN to integer" message...

Agreed. It's an ugly hack. Let's look at it again after Raring.

This bug was fixed in the package pycurl - 7.19.0-5ubuntu7

---------------
pycurl (7.19.0-5ubuntu7) raring; urgency=low

  * debian/patches/lp1063350.patch: Reset the float context after
    closing the curl object. (LP: #1063350)
 -- Barry Warsaw <email address hidden> Thu, 04 Apr 2013 18:53:22 -0400

This bug also affects Linux Mint 13 Mate.
Some package for Precise please ;)
Downgrading "python-software-properties" to version 0.82.7-1-linuxmint2 (maya) or to 0.82.7 (precise) helps.

FWIW: Nathan asked way back in msg #15 for some input, here it finally is, though from another system where I had the same problem (and the q&d dummy-fix worked again):

>>> geturl("https://launchpad.net/api/")
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-bMnApk/pkcs11: No such file or directory
Object: <lp.services.webapp.servers.WebServiceClientRequest instance URL=https://launchpad.net>, name: ''
before: 0.5 0.5
after: nan 0.5

flags: fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pse36 mmx fxsr sse up

Comment #32 dated 2013-04-05: "This bug was fixed in the package pycurl - 7.19.0-5ubuntu7"

The fix has not yet got back to (X)ubuntu 12.04(.2) LTS - considering it is a security-related isssue (securely identifying repositories in add-apt-repository), its backporting should surely be given some urgency - please!

+ sudo true
+ uname -a
Linux Shuttle01 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:40:13 UTC 2013 i686 athlon i386 GNU/Linux
+ grep -E 'name|flags' /proc/cpuinfo
model name : AMD Athlon(tm) XP 2500+
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
+ sudo add-apt-repository ppa:libreoffice/libreoffice-4-0
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py", line 99, in run
    self.add_ppa_signing_key(self.ppa_path)
  File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py", line 132, in add_ppa_signing_key
    tmp_keyring_dir = tempfile.mkdtemp()
  File "/usr/lib/python2.7/tempfile.py", line 322, in mkdtemp
    name = names.next()
  File "/usr/lib/python2.7/tempfile.py", line 141, in next
    letters = [choose(c) for dummy in "123456"]
  File "/usr/lib/python2.7/random.py", line 274, in choice
    return seq[int(self.random() * len(seq))] # raises IndexError if seq is empty
ValueError: cannot convert float NaN to integer

You are about to add the following PPA to your system:
 LibreOffice 4.0.x series stable backports ppa (and SRU-testing for raring)
http://sweetshark.livejournal.com/10977.html

This ppa will:
- not contain alpha and beta releases like 4.0.0~beta2
- not contain updates to the next major (4.1.x)
- contain minor release updates and their release candidates -- these can be
  considered stable

Note that for minor release updates (4.0.1, 4.0.2, 4.0.3 ...) an rc2 is almost always exactly the same as the final version.

see: https://wiki.documentfoundation.org/ReleasePlan for details
 More info: https://launchpad.net/~libreoffice/+archive/libreoffice-4-0
Press [ENTER] to continue or ctrl-c to cancel adding it

This particular bug has been marked as fixed, therefore it shouldn't be reopened. If you are still facing problems, they may be related to an another cause. It's important to file a new bug so that the required information will be submitted to the developers:

  https://help.ubuntu.com/community/ReportingBugs

Once you have reported the bug, feel free to leave a comment here with the new bug number.

This bug on my Maja is still there.
When I unhold package "python-software-properties",
and upgrade them from 0.82.7-1-linuxmint2 to any newer wersion
the bug affects again.
That same is with pycurl - 7.19.0.x package.
Downgraded works. New don't.
:/

Andrea, please be more careful with such broad statements. LP has the option to reopen tickets for a reason. People are apparently still affected, we are still waiting for a precise package and Barry himself said that he wants to look at the issue again after raring.

Reopening.

@Rolf..
Exactly. Many ppl I know, are affected by this bug.
And only workaround for them is to downgrade those two (or one, like on my system) packages.

I'm having this problem too on the living room desktop (grep cpuinfo pasted below). However, I have no problems when running a VM on a 64-bit machine. This desktop is pretty old, so I don't know if that might be a problem.

model name : AMD Athlon(tm)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow

And this is the cause of this problem -> athlon cpu.
Exactly (I think) a lack of sse2 instructions in those cpu's.
My is also athlon model 2400xp from experimental "black edition".

As an update, downgrading python to the version that was suggested above worked and allowed me to install the repository.

That desktop CPU is also quite old, probably almost 10 years by my estimation. It's only 1 GHz.

For reference, I ran the grep on the virtual machine version that works and it has sse2 in the flags.

shall we all just throw this stuff out together........?

On 29 August 2013 17:32, Mark Dowd <email address hidden> wrote:

> As an update, downgrading python to the version that was suggested above
> worked and allowed me to install the repository.
>
> That desktop CPU is also quite old, probably almost 10 years by my
> estimation. It's only 1 GHz.
>
> For reference, I ran the grep on the virtual machine version that works
> and it has sse2 in the flags.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1063350
>
> Title:
> curl corrupts floating point context
>
> Status in “pycurl” package in Ubuntu:
> Triaged
>
> Bug description:
> # add-apt-repository ppa:ubuntu-wine/ppa
> You are about to add the following PPA to your system:
> Welcome to the Wine Team PPA. Here you can get the latest available
> Wine betas for every supported version of Ubuntu. This PPA is managed by
> Scott Ritchie and Maarten Lankhorst.
> More info: https://launchpad.net/~ubuntu-wine/+archive/ppa
> Press [ENTER] to continue or ctrl-c to cancel adding it
>
> Exception in thread Thread-1:
> Traceback (most recent call last):
> File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
> self.run()
> File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py",
> line 99, in run
> self.add_ppa_signing_key(self.ppa_path)
> File "/usr/lib/python2.7/dist-packages/softwareproperties/ppa.py",
> line 132, in add_ppa_signing_key
> tmp_keyring_dir = tempfile.mkdtemp()
> File "/usr/lib/python2.7/tempfile.py", line 322, in mkdtemp
> name = names.next()
> File "/usr/lib/python2.7/tempfile.py", line 141, in next
> letters = [choose(c) for dummy in "123456"]
> File "/usr/lib/python2.7/random.py", line 274, in choice
> return seq[int(self.random() * len(seq))] # raises IndexError if
> seq is empty
> ValueError: cannot convert float NaN to integer
>
> I have tried a purge and install but it doesn't fix this.
>
> No idea how to work around this.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: python-software-properties 0.82.7.3
> ProcVersionSignature: Ubuntu 3.2.0-31.50-generic-pae 3.2.28
> Uname: Linux 3.2.0-31-generic-pae i686
> ApportVersion: 2.0.1-0ubuntu13
> Architecture: i386
> Date: Sun Oct 7 18:43:46 2012
> PackageArchitecture: all
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> LANG=en_GB.UTF-8
> SHELL=/bin/bash
> SourcePackage: software-properties
> UpgradeStatus: Upgraded to precise on 2012-10-03 (4 days ago)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/pycurl/+bug/1063350/+subscriptions
>

The #4 work-around solved this problem on an x86 based install of Xubuntu 12.04.

Was there a security risk in that version of the package that the latest version was suppose to address?

Aptitude is having a hard time locking in that specific back level version, thus thinks there is an update available all the time.

What can I do to assist with resolving this bug? TIA!

I'm now working on pycurl 7.19.5 for Debian and I was looking at porting over as much of the Ubuntu delta as possible. I think the patch for this is no longer necessary, but it's difficult for me to test because I also no longer have an i386 machine on which to test. Note though that we are now linking against gnutls 2.8, so if the suspicion is that the bug is in gnutls 2.6, maybe it's fixed in 2.8 and pycurl won't be subject to the bug.

In any case, I am not going to back port this fix, so we'll have to see if anybody reports a bug once the package is pulled into Ubuntu.

I've verified this patch is no longer necessary with pycurl 7.19.5, which I will FFe shortly into Utopic. It could be building it against gnutls28, or changes in pycurl itself.

I think that #41 is right (Athlon cpu is causing it)

my cpu: AMD Sempron(tm) 2400+

On Oct 14, 2014, at 01:19 PM, ינון-דוד-צדוק (Yinon-David-Zadok) wrote:

>I think that #41 is right (Athlon cpu is causing it)
>
>my cpu: AMD Sempron(tm) 2400+

But is it still reproducible on Ubuntu 14.10 with the latest PyCURL?

>But is it still reproducible on Ubuntu 14.10 with the latest PyCURL?

Im not an expert, I just saw that amd cpu(s) ARE related (I think).
But, do you ask if the fix is reproducible? or if the bug is reproducible?

Anyway I've never installed 14.10. You can try the solution in comment #4

Command (fix) with sudo:
sudo apt-get install python-software-properties=0.82.7

Right, I meant that I can no longer reproduce the problem on 14.10. It could be because I don't have the right hardware anymore to trigger it, but I think it's more likely that something in the Utopic stack has essentially fixed the problem. Any, for others who many stumble upon this bug in the future, please reopen it if you can still reproduce it in 14.10 or later.

I don't have an AMD CPU. But I do have a bit of an odd-ball CPU from VIA. Not sure if that even was the affected machine, though.

$ grep -E "name|flags" /proc/cpuinfo
model name : VIA Samuel
flags : fpu de tsc msr mce cx8 mtrr pge mmx 3dnow up

I was unable to reproduce this today on the VIA-machine running hardy as well as a trusty more conventional laptop. Output was identical in both cases, not showing NaN.

$ python
Python 2.6.5 (r265:79063, Feb 27 2014, 19:44:14)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pycurl
>>> def geturl(url):
... curl=pycurl.Curl()
... curl.setopt(pycurl.URL,url)
... curl.perform()
... print
... print "before:", 1.0/2, 1.0/2
... curl.close()
... print "after:", 1.0/2, 1.0/2
...
>>> geturl("https://launchpad.net/api/")
Object: <lp.services.webapp.servers.WebServiceClientRequest instance URL=https://launchpad.net>, name: ''
before: 0.5 0.5
after: 0.5 0.5

Feel free to close as fixed, if you ask me.

On Dec 18, 2014, at 03:13 PM, Rolf Leggewie wrote:

>Feel free to close as fixed, if you ask me.

Thanks.

Thanks Barry, Nathan and Ken!