test_resource does:

print resource.RLIM_INFINITY == max

I'm not sure of the benefit of this line. For machines
which have limited file sizes, it causes the test to fail.
Otherwise the test seems to work properly.

Logged In: YES
user_id=33168

Martin, welcome back! Now I get to assign some bugs to you
to see if you have any input. :-)

Logged In: YES
user_id=21627

The rationale of the line is explained in the comment: The
code tests whether the limit is a really large number, i.e.
whether represenation of large limits works.

Unfortunately, it doesn't (which is a separate issue): On
Linux, RLIM_INFINITY is reported as -1. This comes from
RLIM_INFINITY being the larges unsigned long long number,
i.e. 0xffffffffffffffffuLL. The resource module represents
this incorrectly.

I think there is no way to verify that Python computes the
real limit correctly (unless we invoke the shell's ulimit
for comparison). So you could weaken the test to verify that
the limit is non-negative (and, as a side effect, verify
that it doesn't raise an exception).

If you do so, you'll also have to fix the implementation, so
that the weakened-strengthened test passes on Linux.

Logged In: YES
user_id=33168

Hmmm, sounds like a lot of work. How about something like this:

    expected_max = resource.RLIM_INFINITY
    if expected_max != max:
        # read the file resource limit
        fsize_ulimit = os.popen('ulimit -f').read()
        try:
            # convert the file size to bytes (from 512 byte
blocks)
            expected_max = int(fsize_ulimit.strip()) * 512
        except ValueError:
            raise TestSkipped, "unable to determine expected
resource value"
    print expected_max == max

This works, but I'm pretty sure this is not portable. On
Linux blocks are 1k. This only works when the block size is
512 bytes. Shall we close this bug as a test environment
problem and won't fix?

Logged In: YES
user_id=21627

I'm really not that much concerned about fixing the test,
but more about fixing the code itself.

Logged In: YES
user_id=994239

I'm running into this problem under AIX 4.3.3 and 5.1. Is
this going to cause a problem if I put python into
production, or is it "safe" to ignore it?

Is this still a problem?

Closed as no response to msg81850.

The test does not fail if FSIZE is not max on linux/py3k, but max is still represented as -1 on linux. So the reported bug is no longer valid, but Martin's concern has not been addressed.

As a point of information, on my gentoo linux system without largefile support in the kernel, any value 4294967295 or above results in getrlimit reporting -1. Any smaller value is set and reported as itself. (If a sufficiently large value is passed in to setrlimit, an OverflowError results.)

As a point of information, on my gentoo linux system without
largefile support in the kernel, any value 4294967295 or above
results in getrlimit reporting -1. Any smaller value is set and
reported as itself. (If a sufficiently large value is passed in to
setrlimit, an OverflowError results.)

I think we really should create new issues for any remaining problems.

AFAICT, the remaining problems are:

• resource.RLIM_INFINITY is -1 on Linux, when it is meant to be
  a really large value
• (as you reported) getrlimit returns -1 to indicate RLIM_INFINITY.

I think the core of the problem is that the resource module considers
rlim_t to be a signed type (or at least representable in "long long").
Using FromUnsignedLongLong in the appropriate place might solve the
issue.

For info:
this test fails on AIX 6.1 with py3k with the following error:

test test_resource failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_resource.py", line 28, in test_fsize_ismax
    self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 2147483647 != 1073741312

The same test works on AIX 5.3.

Is it related or should I open a new issue?

I suppose the difference comes from the fact that I have:
on AIX 5.3:
$ ulimit -f
unlimited

on AIX 6.1:
$ ulimit -f
1048575

I think the test should be updated to not require "ulimit -f" is unlimited.

That's what the original report is about, as opposed to the linux repr issue that Martin wants to break out into a new ticket (which I will do). Any ideas how to fix the test? It didn't fail for me on linux, so I don't have a good test platform for trying to fix it.

I'm un-assigning Neal since the original report is no longer the cause of the test error. (The test has obviously changed since we don't check print output any more.)

The ideal would be to check that RLIMIT_FSIZE corresponds to the ulimit as it has been suggested by Neal Norwitz in msg14345, but since the value reported by ulimit has a different unit for each platform, that would be quite a lot of trouble.

All I can suggest is the following, which checks that both values are somewhat reasonable.

Index: Lib/test/test_resource.py
===================================================================

--- Lib/test/test_resource.py	(révision 84964)
+++ Lib/test/test_resource.py	(copie de travail)
@@ -20,12 +20,17 @@
         except AttributeError:
             pass
         else:
-            # RLIMIT_FSIZE should be RLIM_INFINITY, which will be a really big
-            # number on a platform with large file support.  On these platforms,
-            # we need to test that the get/setrlimit functions properly convert
-            # the number to a C long long and that the conversion doesn't raise
-            # an error.
-            self.assertEqual(resource.RLIM_INFINITY, max)
+            # RLIMIT_FSIZE should be RLIM_INFINITY if 'ulimit -f' is
+            # set to unlimited
+            # RLIM_INFINITY will be a really big number on a platform
+            # with large file support.  On these platforms, we need to
+            # test that the get/setrlimit functions properly convert
+            # the number to a C long long and that the conversion
+            # doesn't raise an error.            
+            self.assertGreater(resource.RLIM_INFINITY, 0)
+            self.assertLessEqual(cur, max)
+            self.assertGreater(max, 0)
+            self.assertLessEqual(max, resource.RLIM_INFINITY)
             resource.setrlimit(resource.RLIMIT_FSIZE, (cur, max))
 
     def test_fsize_enforced(self):

The inline patch in msg117130 has never been committed from what I can see. Can somebody review it please as I'm assuming that it's still valid.

Can somebody take a look at this please. See also bpo-9917.

This issue is still relevant and can be reproduced by running:

ulimit -Hf 1000
./python [Lib/test/test_resource.py](https://github.com/python/cpython/blob/main/Lib/test/test_resource.py)

(On AIX, the default hard limit is not RLIM_INFINITY so it reproduces on that operating system without the first line)

The patch is still relevant and fixes the issue.
It looks like it's doing the right thing, but it can't be committed until bpo-9917 will be fixed - otherwise the tests will break on Linux, where RLIM_INFINITY is -1 and not greater than 0.

The test does not fail if FSIZE is not max on linux/py3k, but max is still represented as -1 on linux. So the reported bug is no longer valid, but Martin's concern has not been addressed.

Is the issue relevant (or fixable) on modern systems? It was raised 20 years ago so OS behavior could change drastically.

For context: the reported chunk is: