> I'm wondering if the NaN arises in the C code for random():

I don't think that's possible.  In the second line:

    return PyFloat_FromDouble((a*67108864.0+b)*(1.0/9007199254740992.0));

a and b are already C unsigned longs, so no matter what their value, the result of the expression is well in range for an IEEE 754 double, and on a normal machine there's just no realistic way that this calculation could produce a NaN.  PyFloat_FromDouble does no manipulation of the C double, but just stores it directly in the PyFloat object.


I think there are two different things going on here.

(1) The Ubuntu error reporter seems to be using something other than the standard Random class, so all bets are off there without knowing more about what's being used.  Chances seem good that whatever random number generator they're using really *is* producing a NaN.

(2) That leaves Greg's report above, where the standard Random class is apparently what's being used.  Here I'm baffled---I can't see any realistic mechanism that might produce that traceback.