[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

python 2.4: os.urandom() hangs if /dev/random, /dev/urandom are not reco

From: massimo s.
Subject: python 2.4: os.urandom() hangs if /dev/random, /dev/urandom are not reconnected to a translator
Date: Thu, 25 Jan 2007 23:36:01 +0000
User-agent: Mozilla Thunderbird (X11/20070123)

I noticed that gconf-schemas was hung (even overnight) until ctrl-c is
pressed. This prevented correct installation (and disinstallation) of
xchat-common deb binary package.

I'm using Debian gnu/hurd K14.

When using ctrl-c python gives the following traceback, showing the
instruction where it hangs:

Traceback (most recent call last):
File "/usr/lib/python2.4/tempfile.py", line 33, in ?
        from random import Random as _Random
File "/usr/lib/python2.4/random.py", line 834, in ?
        inst = Random()
File "/usr/lib/python2.4/random.py", line 94, in __init__
File "/usr/lib/python2.4/random.py", line 108, in seed
        a = long(_hexlify(_urandom(16)), 16)
File "/usr/lib/python2.4/os.py", line 723, in urandom
        bytes += read(_urandomfd, n - len(bytes))

The bug can be simply reproduced by launching python and issuing the
following two commands:
>>> import os
>>> os.urandom(16) #this may be any number

At first I tried showtrans on the /dev/random, /dev/urandom devices and
I found they were attached to the unofficial translator
Resetting /dev/random, /dev/urandom by detaching (settrans -fg
/dev/urandom) and then reattaching the translator fixed the bug. If I
release the translator the bug comes out again.

Judging from the behaviour traceback, I think that when the translator
is not attached, os.urandom() tries to read a random stream that doesn't
exist, so it hangs until the right number of bytes arrives... that is,
never. However the translator *was* attached before; so maybe it's
(also) a translator bug. I was root when testing, so I doubt a
permission issue.

I have some Python knowledge so I can try to patch os.urandom() to
behave correctly (or at least throw an exception noticing that there is
no translator bound to the device/he can't have the stream). The bug is
of some importance because at least gconf-schemas depends on it, and it
prevents installation of some packages. To my knowledge (Googling
"os.urandom + hurd" :) ) the bug is unknown.

What should I do? Contact the upstream os module developers? or do we
need to "unofficially" patch it for the gnu Hurd?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]