Bug 653850 – dev-lang/python fails test_fsize_ismax (test.test_resource.ResourceTest) on alpha

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Matt Turner 2018-04-23 02:19:32 UTC]

Created attachment 528240 [details]
python-3.4.8.log

Reproduced on python-3.4.8, 3.5.5, and 3.6.5.

======================================================================
FAIL: test_fsize_ismax (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.4.8/work/Python-3.4.8/Lib/test/test_resource.py", line 31, in test_fsize_ismax
    self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 9223372036854775807 != -1

----------------------------------------------------------------------
Ran 10 tests in 0.582s

FAILED (failures=1)
test test_resource failed
1 test failed again:
    test_resource

[Comment 1 Matt Turner 2018-04-23 02:26:07 UTC]

On alpha:

Python 3.6.5 (default, Apr 22 2018, 18:05:17) 
[GCC 6.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import resource
>>> resource.RLIM_INFINITY,
(9223372036854775807,)
>>> 

On amd64:

Python 3.6.3 (default, Mar 19 2018, 14:16:48) 
[GCC 6.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import resource
>>> resource.RLIM_INFINITY,
(-1,)

On ppc/ppc64:

Python 3.6.5 (default, Apr 22 2018, 18:10:12) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import resource
>>> resource.RLIM_INFINITY
-1

[Comment 2 Matt Turner 2018-09-12 05:45:33 UTC]

This was a regression in glibc-2.25 and I believe is fixed in 2.27.

[Comment 3 Matt Turner 2018-09-15 01:45:45 UTC]

Indeed updating to glibc-2.27 fixes that problem, and turns up another:

0:11:46 load avg: 5.74 [375/405/1] test_resource failed
test test_resource failed -- Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.6.5/work/Python-3.6.5/Lib/test/support/__init__.py", line 555, in wrapper
    return func(*args, **kw)
  File "/var/tmp/portage/dev-lang/python-3.6.5/work/Python-3.6.5/Lib/test/test_resource.py", line 172, in test_prlimit_refcount
    self.assertEqual(resource.prlimit(0, resource.RLIMIT_AS, BadSeq()),
PermissionError: [Errno 1] Operation not permitted

Possible that it existed previously but the test bailed after the first failure.

[Comment 4 matoro 2022-09-22 23:08:48 UTC]

Created attachment 813730 [details, diff]
glibc patch to fix new failure

[Comment 5 Andreas K. Hüttel 2023-08-24 20:27:05 UTC]

(In reply to matoro from comment #4)
> Created attachment 813730 [details, diff] [details, diff]
> glibc patch to fix new failure

matoro: is this already upstreamed? if not could you please file a bug for glibc and attach it there?

[Comment 6 matoro 2023-08-24 23:05:42 UTC]

(In reply to Andreas K. Hüttel from comment #5)
> (In reply to matoro from comment #4)
> > Created attachment 813730 [details, diff] [details, diff] [details, diff]
> > glibc patch to fix new failure
> 
> matoro: is this already upstreamed? if not could you please file a bug for
> glibc and attach it there?

We submitted it but aurel seems to indicate it was incorrect:  https://sourceware.org/pipermail/libc-alpha/2022-October/142589.html

At this point I'm not confident I did it correctly, but aurel seems to have no inclination to correct it.  I'm also unsure if the fundamental objection to the behavior (breaking the expectation of getrlimit() returning some value x after a successful call to setrlimit(x)) is "blocking" or not.  If you could poke in and revive the thread it might stimulate discussion again.

[Comment 7 Sam James 2023-08-26 04:50:43 UTC]

Can you file a bug as well upstream please?

[Comment 8 matoro 2023-10-23 20:39:25 UTC]

Opened a bug https://sourceware.org/bugzilla/show_bug.cgi?id=30992