resource.h broken (not implemented yet?)

[scottmc]

May be related to ticket #2817 perhaps not, python's test_resource.py passes the first test, then fails the next 3 and then crashes on getrusage.

~/develop/python/Lib/test> python test_resource.py
test_args (__main__.ResourceTest) ... ok
test_fsize_enforced (__main__.ResourceTest) ... ERROR
test_fsize_ismax (__main__.ResourceTest) ... ERROR
test_fsize_toobig (__main__.ResourceTest) ... ERROR
test_getrusage (__main__.ResourceTest) ... Kill Thread
~/develop/python/Lib/test> 

[Timothy_Gu]

The first three errors are easily reproducible with

#include <errno.h>
#include <stdio.h>
#include <sys/resource.h>

int
main()
{
    struct rlimit rl = {0};
    int ret;
    ret = get_rlimit(RLIMIT_FSIZE, &rl);
    printf("%d %d %" __HAIKU_PRI_PREFIX_ADDR "d %" __HAIKU_PRI_PREFIX_ADDR "d\n", ret, errno, rl.rlim_cur, rl.rlim_max);
    return ret;
}

[Timothy_Gu]

Apparently only part of POSIX spec for [gs]et_rlimit is implemented, and when it encounters an unimplemented property it just returns EINVAL.

See ​https://github.com/haiku/haiku/blob/449f7f5a7b9d381c1eeab3ddfbdba0db0ce05c22/src/system/kernel/thread.cpp#L1310-L1327

I'm not sure what the right thing to do is here. Should I make it return ENOSYS instead? But that would break a lot of apps relying on POSIX. Or I could make it return 0 as the values.

List of unimplemented properties:

• RLIMIT_CPU: maximum amount of CPU time, in seconds, used by a process
• RLIMIT_DATA: maximum size of a process' data segment, in bytes
• RLIMIT_FSIZE: maximum size of a file, in bytes, that may be created by a process
• RLIMIT_STACK (implemented in get_rlimit() but not in set): maximum size of the initial thread's stack, in bytes
• RLIMIT_AS: maximum size of a process' total available memory, in bytes

I will investigate the getrusage() failure soon.

[Timothy_Gu]

The getrusage() function itself works fairly well, from my standalone test program. I believe the issue is in one of the patches applied to get python to build, as the segfault seems to be from the python internals. I will try to confirm.

[Timothy_Gu]

Interestingly, the getrusage() issue only seems to be reproducible on x86_gcc2. x86_64 does not have this issue. I will test pure x86 soon.

[Timothy_Gu]

My program used to test getrusage():

#include <errno.h>
#include <stdio.h>
#include <sys/resource.h>

// From https://github.com/python/cpython/blob/2.7/Modules/resource.c#L20
#define doubletime(TV) ((double)(TV).tv_sec + (TV).tv_usec * 0.000001)

int
main()
{
    struct rusage ru = {0};
    int ret;
    ret = getrusage(RUSAGE_SELF, &ru);
    printf("%d %d %f %f\n", ret, errno, doubletime(ru.ru_utime), doubletime(ru.ru_stime));
    return ret;
}

It prints something like this:

0 0 0.1034 0.1620

The first two 0's indicate that there is no error (ret and errno resp.).

[Timothy_Gu]

Unfortunately no, getrusage() doesn't work on x86_gcc4 either.

[Timothy_Gu]

Hah found where the issue is. It is in a patch in Python. Will submit a PR to haikuports soon.

[pulkomandy]

Please include a link to your PR so we can check and close this. Thanks for investigating!

[Timothy_Gu]

Replying to pulkomandy:

Please include a link to your PR so we can check and close this. Thanks for investigating!

Here: ​https://bitbucket.org/haikuports/haikuports/pull-request/453/fix-python-resource-module/diff

[pulkomandy]

Ok, PR is merged. It would still be nice to actually implement things so we don't have to hack around it in Python sources, but at least the crash is fixed now.

[owenca]

Added RLIMIT_AS, RLIMIT_DATA, and RLIMIT_STACK for setrlimit() to match getrlimit(). Please see the attached patch.

[pulkomandy]

I don't think this is the right way to go about it. Either we don't support changing the values, and we always return EINVAL (this is what happens now). Or, we do support setting them, and by this I mean also setting them to a value other than the default.

With your changes, the function now returns "ok" in some cases, which makes it harder to check wether actually changing the value is possible, but no functionality is gained. This is not of much use.

[owenca]

Because the existing code doesn't support RLIMIT_CORE and doesn't always return EINVAL in common_setrlimit, I made the other rlimits to match the behavior. So the current way of handling RLIMIT_CORE in common_setrlimit is also wrong?

[pulkomandy]

Patch migrated to Gerrit: ​https://review.haiku-os.org/79

[cocobean]

Checked with POSIX.1-2017 spec. PASSES.