test test_pwd failed -- Traceback (most recent call last):
  File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum


$ cat /proc/version 
Linux version 2.4.21-20.ELsmp
(bhcompile@dolly.build.redhat.com) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004

Processor is AMD Opteron 2.4MHz

Logged In: YES 
user_id=358087

Ran with -v:
$ ./python Lib/test/test_pwd.py -v
test_errors (__main__.PwdTest) ... ok
test_values (__main__.PwdTest) ... ERROR

======================================================================
ERROR: test_values (__main__.PwdTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum

----------------------------------------------------------------------
Ran 2 tests in 0.480s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 92, in ?
    test_main()
  File "Lib/test/test_pwd.py", line 89, in test_main
    test_support.run_unittest(PwdTest)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 290, in run_unitt                                     
       est
    run_suite(suite, testclass)
  File "/tmp/miki/Python-2.4b2/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_pwd.py", line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum

Logged In: YES 
user_id=33168

I just tested this on an opteron and it ran ok, so this
problem isn't necessarily opteron/64-bit specific.  What is
the largest user id on the system?  What is the value of
pw_uid that is causing a problem?  Can you attach your
/etc/passwd file?  If so, you may want to change any user info.

I have:
  nobody:x:65534:65534:nobody:/:/bin/false

I tried adding another nobody with a larger uid, but did not
have any problems with the test.  This is on a gentoo system.

Logged In: YES 
user_id=358087

1. How do I find the largest user id?
2. It's 4294967294
3. Can't attach etc/password since it's a company machine
(IT will kill me :-)
    However there is a similar line for nobody with 65534

The hardware is 4 CPU with 16GB of memory.
OS is: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)

Logged In: YES 
user_id=89016

On a 32bit system adding the line
nobody:x:4294967294:65534:nobody:/:/bin/false
to /etc/passwd pwd.getpwall() gives me an entry:
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')
and
pwd.getpwuid(-2)
gives me
('nobody', 'x', -2, 65534, 'nobody', '/', '/bin/false')

Maybe for 64bit systems the SETI macro should use
PyLong_FromUnsignedLong() instead of PyInt_FromLong()? Can
you try the following patch?

Logged In: YES 
user_id=358087

I've tried the patch - no luck :-(

I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...

Logged In: YES 
user_id=1035073

The same error occurs for an Intel P4-521 processor running
RedHat Enterprise Linux WS v4 Intel EM64T 64bit.
$ cat /proc/version
Linux version 2.6.9-5.ELsmp (bhcompile@thor.perf.redhat.com)
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP
Wed Jan 5 19:29:47 EST 2005

test test_grp failed -- Traceback (most recent call last):
  File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py",
line 29, in test_values
    e2 = grp.getgrgid(e.gr_gid)
OverflowError: signed integer is greater than maximum

test test_pwd failed -- Traceback (most recent call last):
  File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py",
line 42, in test_values
    self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum

Logged In: YES 
user_id=298758

I think I figued out the problem with python handling uids and 
gids greater than 2147483647 when using the grp.getgrgid 
and pwd.getpwuid functions. Both of the functions call 
PyArg_ParseTuple with a type of "i", thus indicating the 
argument is a signed integer. Instead they should be 
using "I" (upper-case i) for an unsigned integer. The fix is 
fairly simple. Here are the two patches necessary to the 
python source:

diff -Naur Python-2.4.orig/Modules/grpmodule.c Python-
Modules/grpmodule.c
--- Python-2.4.orig/Modules/grpmodule.c 2004-01-20 
16:06:00.000000000 -0500
+++ Python-2.4/Modules/grpmodule.c      2005-08-11 
13:36:48.000000000 -0400
@@ -87,7 +87,7 @@
 {
     int gid;
     struct group *p;
-    if (!PyArg_ParseTuple(args, "i:getgrgid", &gid))
+    if (!PyArg_ParseTuple(args, "I:getgrgid", &gid))
         return NULL;
     if ((p = getgrgid(gid)) == NULL) {
        PyErr_Format(PyExc_KeyError, "getgrgid(): gid not 
found: %d", gid);

diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python-
Modules/pwdmodule.c
--- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20 
16:07:23.000000000 -0500
+++ Python-2.4/Modules/pwdmodule.c      2005-08-11 
13:36:27.000000000 -0400
@@ -104,7 +104,7 @@
 {
        int uid;
        struct passwd *p;
-       if (!PyArg_ParseTuple(args, "i:getpwuid", &uid))
+       if (!PyArg_ParseTuple(args, "I:getpwuid", &uid))
                return NULL;
        if ((p = getpwuid(uid)) == NULL) {
                PyErr_Format(PyExc_KeyError,

Hopefully, someone from the python project can verify my 
patch and get it incorporated into a future release.

Logged In: YES 
user_id=1035073

The suggested patch by heffler worked brilliantly for my 64
bit environment.  Thanks.  My bug submission was on
2005-08-03 14:40.

Logged In: YES 
user_id=1188172

Is the patch safe to apply? I think so, I haven't seen a
negative uid/gid yet.

Logged In: YES 
user_id=33168

See this patch which looks like it may fix the same problem
(among others).

https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470

Logged In: YES 
user_id=6380

Martin, IMO you can close this now that I've checked in the
AIX patch which should address this with the i->I change
suggested in a comment below. (patch 1284289)

Logged In: YES 
user_id=1188172

Closing as requested.