setrlimit always fails

setrlimit always fails

[Patrick Chkoreff]

I'm trying to use setrlimit to impose limits on various resources such
as CPU time and memory.  The call to setrlimit always fails.  I've
distilled this into the following example test.c:

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

int main(void)
    {
    struct rlimit rlim;
    rlim.rlim_cur = 1;
    rlim.rlim_max = 1;
    if (setrlimit(RLIMIT_CPU,&rlim) < 0)
        {
        perror("setrlimit");
        exit(1);
        }
    printf("HEY\n");
    while (1)
        {
        }
    printf("BYE\n");
    return 0;
    }

$ gcc test.c
$ ./a.exe
setrlimit: Invalid argument


I have found that the only way to make the setrlimit call succeed is to
use RLIM_INFINITY:

    rlim.rlim_cur = RLIM_INFINITY;
    rlim.rlim_max = RLIM_INFINITY;

But then of course it does not achieve the desired result of timing out
after 1 second.

Any ideas?


-- Patrick

Re: setrlimit always fails

[Ken Brown]

On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
> I'm trying to use setrlimit to impose limits on various resources such
> as CPU time and memory.  The call to setrlimit always fails.  I've
> distilled this into the following example test.c:
[...]
>      if (setrlimit(RLIMIT_CPU,&rlim) < 0)
[...]
> setrlimit: Invalid argument

Cygwin's setrlimit only supports a few resources, as you can see in the source:

https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201

Ken

Re: setrlimit always fails

[Brian Inglis]

On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
> On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
>> I'm trying to use setrlimit to impose limits on various resources such
>> as CPU time and memory.  The call to setrlimit always fails.  I've
>> distilled this into the following example test.c:
> [...]
>>      if (setrlimit(RLIMIT_CPU,&rlim) < 0)
> [...]
>> setrlimit: Invalid argument
> 
> Cygwin's setrlimit only supports a few resources, as you can see in the source:
> 
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201 

In that case could I suggest:

	/usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
	https://cygwin.com/cygwin-api/compatibility.html#std-susv4

in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml

get/setrlimit entries should be annotated with:

	(see chapter "Implementation Notes")

and all those entries should be links to "std-notes":

	/usr/share/doc/cygwin-doc/html/cygwin-api/std-notes.html
	https://cygwin.com/cygwin-api/std-notes.html

	<ulink url="std-notes.html">(see chapter "Implementation Notes")</ulink>

in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml

which should have an entry documenting the limitations of get/setrlimit like e.g.

"<para><function>getrlimit</function> resources RLIMIT_AS, RLIMIT_CPU, 
RLIMIT_FSIZE, RLIMIT_DATA always return rlim_cur and rlim_max as RLIM_INFINITY, 
so <function>setrlimit</function> returns -1 and sets EINVAL if they are 
lowered, or returns 0 if unchanged.
<function>getrlimit</function> resource RLIMIT_NOFILE always returns rlim_cur 
and rlim_max as OPEN_MAX; <function>setrlimit</function> returns 0 sets EINVAL 
if rlim_cur > rlim_max, does not change the value if it is RLIM_INFINITY, 
otherwise returns the result from <function>setdtablesize</function>.
<function>getrlimit</function>/<function>setrlimit</function> resources 
RLIMIT_CORE and RLIMIT_STACK return the current values and set the requested values.
All other resource arguments return -1 and set EINVAL.</para>"

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: setrlimit always fails

[Corinna Vinschen]

On Feb 12 00:26, Brian Inglis wrote:
> On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
> > On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
> > > I'm trying to use setrlimit to impose limits on various resources such
> > > as CPU time and memory.  The call to setrlimit always fails.  I've
> > > distilled this into the following example test.c:
> > [...]
> > >      if (setrlimit(RLIMIT_CPU,&rlim) < 0)
> > [...]
> > > setrlimit: Invalid argument
> > 
> > Cygwin's setrlimit only supports a few resources, as you can see in the source:
> > 
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201
> 
> In that case could I suggest:
> 
> 	/usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
> 	https://cygwin.com/cygwin-api/compatibility.html#std-susv4
> 
> in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml
> 
> get/setrlimit entries should be annotated with:

https://cygwin.com/acronyms/#PGA


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: setrlimit always fails

[Brian Inglis]

On 2021-02-12 02:12, Corinna Vinschen via Cygwin wrote:
> On Feb 12 00:26, Brian Inglis wrote:
>> On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
>>> On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
>>>> I'm trying to use setrlimit to impose limits on various resources such
>>>> as CPU time and memory.  The call to setrlimit always fails.  I've
>>>> distilled this into the following example test.c:
>>> [...]
>>>>       if (setrlimit(RLIMIT_CPU,&rlim) < 0)
>>> [...]
>>>> setrlimit: Invalid argument
>>>
>>> Cygwin's setrlimit only supports a few resources, as you can see in the source:
>>>
>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201
>>
>> In that case could I suggest:
>>
>> 	/usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
>> 	https://cygwin.com/cygwin-api/compatibility.html#std-susv4
>>
>> in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml
>>
>> get/setrlimit entries should be annotated with:
> 
> https://cygwin.com/acronyms/#PGA

I'll see what I can do. Does anyone know if <ulink> is supported within 
<screen>? I seem to remember struggles updating proc(5) in specialnames.xml.

It appears that code using other than the common POSIX resources need existence 
checks.
I am unsure if it is worth adding definitions for any others.
It may be possible to implement RSS, NPROC, LOCKS, NICE, but
https://cygwin.com/acronyms/#SHDTI

Comparing Cygwin and Linux ([uapi/]asm-generic/}:

#define RLIMIT_CPU		0	/* CPU time in seconds */
#define RLIMIT_FSIZE		1	/* Maximum filesize */
#define RLIMIT_DATA		2	/* max data size */
#define RLIMIT_STACK		3	/* max stack size */
#define RLIMIT_CORE		4	/* max core file size */
#ifdef LINUX
#define RLIMIT_RSS		5	/* max resident set size */
#define RLIMIT_NPROC		6	/* max number of processes */
#define RLIMIT_NOFILE		7	/* max number of open files */
#define RLIMIT_AS		9	/* address space limit */
#else
#define RLIMIT_NOFILE		5	/* max number of open files */
#define RLIMIT_OFILE		RLIMIT_NOFILE	/* BSD name */
#define RLIMIT_AS		6	/* address space limit */
#endif
#ifdef LINUX
#define RLIMIT_LOCKS		10	/* maximum file locks held */
#define RLIMIT_SIGPENDING	11	/* max number of pending signals */
#define RLIMIT_MSGQUEUE		12	/* maximum bytes in POSIX mqueues */
#define RLIMIT_NICE		13	/* max nice prio allowed to raise to */
#define RLIMIT_RTPRIO		14	/* maximum realtime priority */
#define RLIMIT_RTTIME		15	/* timeout for RT tasks in us */
#define RLIM_NLIMITS		16
#else
#define RLIMIT_NLIMITS		7	/* upper bound of RLIMIT_* defines */
#endif

Linux man says:

"RLIMIT_MEMLOCK and RLIMIT_NPROC derive from BSD and are not specified in 
POSIX.1; they are present on the BSDs and Linux, but on few other implementations.
RLIMIT_RSS derives from BSD and is not specified in POSIX.1; it is nevertheless 
present on most implementations.
RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO,  RLIMIT_RTTIME, and 
RLIMIT_SIGPENDING are Linux-specific."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: setrlimit always fails

[Brian Inglis]

On 2021-02-12 11:56, Brian Inglis wrote:
> On 2021-02-12 02:12, Corinna Vinschen via Cygwin wrote:
>> On Feb 12 00:26, Brian Inglis wrote:
>>> On 2021-02-11 19:06, Ken Brown via Cygwin wrote:
>>>> On 2/11/2021 10:23 AM, Patrick Chkoreff wrote:
>>>>> I'm trying to use setrlimit to impose limits on various resources such
>>>>> as CPU time and memory.  The call to setrlimit always fails.  I've
>>>>> distilled this into the following example test.c:
>>>>>       if (setrlimit(RLIMIT_CPU,&rlim) < 0)
>>>>> setrlimit: Invalid argument

>>>> Cygwin's setrlimit only supports a few resources, as you can see in the source:
>>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201 

>>> In that case could I suggest:
>>>     /usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4
>>>     https://cygwin.com/cygwin-api/compatibility.html#std-susv4
>>> in https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml
>>> get/setrlimit entries should be annotated with:

>> https://cygwin.com/acronyms/#PGA

> I'll see what I can do. Does anyone know if <ulink> is supported within 
> <screen>? I seem to remember struggles updating proc(5) in specialnames.xml.
> It appears that code using other than the common POSIX resources need existence 
> checks.
> I am unsure if it is worth adding definitions for any others.
> It may be possible to implement RSS, NPROC, LOCKS, NICE, but
   https://cygwin.com/acronyms/#SHTDI
> 
> Comparing Cygwin and Linux ([uapi/]asm-generic/}:
> 
> #define RLIMIT_CPU		0	/* CPU time in seconds */
> #define RLIMIT_FSIZE		1	/* Maximum filesize */
> #define RLIMIT_DATA		2	/* max data size */
> #define RLIMIT_STACK		3	/* max stack size */
> #define RLIMIT_CORE		4	/* max core file size */
> #ifdef LINUX
> #define RLIMIT_RSS		5	/* max resident set size */
> #define RLIMIT_NPROC		6	/* max number of processes */
> #define RLIMIT_NOFILE		7	/* max number of open files */
   #define RLIMIT_MEMLOCK	8	/* max locked-in-memory address space */
> #define RLIMIT_AS		9	/* address space limit */
> #else
> #define RLIMIT_NOFILE		5	/* max number of open files */
> #define RLIMIT_OFILE		RLIMIT_NOFILE	/* BSD name */
> #define RLIMIT_AS		6	/* address space limit */
> #endif
> #ifdef LINUX
> #define RLIMIT_LOCKS		10	/* maximum file locks held */
> #define RLIMIT_SIGPENDING	11	/* max number of pending signals */
> #define RLIMIT_MSGQUEUE	12	/* maximum bytes in POSIX mqueues */
> #define RLIMIT_NICE		13	/* max nice prio allowed to raise to */
> #define RLIMIT_RTPRIO		14	/* maximum realtime priority */
> #define RLIMIT_RTTIME		15	/* timeout for RT tasks in us */
> #define RLIM_NLIMITS		16
> #else
> #define RLIMIT_NLIMITS	7	/* upper bound of RLIMIT_* defines */
> #endif
> 
> Linux man says:
> 
> "RLIMIT_MEMLOCK and RLIMIT_NPROC derive from BSD and are not specified in 
> POSIX.1; they are present on the BSDs and Linux, but on few other implementations.
> RLIMIT_RSS derives from BSD and is not specified in POSIX.1; it is nevertheless 
> present on most implementations.
> RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO,  RLIMIT_RTTIME, and 
> RLIMIT_SIGPENDING are Linux-specific."

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: setrlimit always fails

[Patrick Chkoreff]

Ken Brown via Cygwin wrote on 2/11/21 9:06 PM:

> Cygwin's setrlimit only supports a few resources, as you can see in the
> source:
> 
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201

Thank you to all who replied.  Shortly after I sent the email, I did
some more searching and did find some posts to that effect, including
one that said setrlimit was originally added as a stub to support
porting OpenSSH.

Also thank you for the pointer to the source code.

The reason I'm asking about setrlimit is that I'm porting the code for
my functional programming language "Fexl" from Linux to Windows under
Cygwin.  (https://fexl.com)

In that language I have embedded functions limit_time, limit_stack, and
limit_memory which call setrlimit.  Those functions can be used to set
sensible limits before running potentially dangerous code.  It's safe
enough to allow running a program entered by a stranger in a text area
on a web site -- even a program which deliberately tries to use an
unbounded amount of memory.

I don't know if native Windows provides enough to flesh out setrlimit
with the equivalent behavior on Linux, even for my very limited usage
(RLIMIT_CPU, RLIMIT_STACK, RLIMIT_AS).  Therefore the only way for me to
do safe limits in Fexl would be to actually count evaluation steps in my
evaluation loop, and memory usage in my allocation wrapper, and halt the
program if it exceeds any user-imposed limits.

So I would have to check evaluation steps here:

https://github.com/chkoreff/Fexl/blob/956bdf85ff5046ebfa7fe582584fedc6881152db/src/value.c#L137

And check memory usage here:

https://github.com/chkoreff/Fexl/blob/956bdf85ff5046ebfa7fe582584fedc6881152db/src/memory.c#L28

It's either that or deprecate my usage of setrlimit altogether, making
it impossible to protect against runaway execution of potentially
dangerous unvetted code.

I will say that my first attempt at compiling the Linux code under
Cygwin went very well.  The only compiler error was in some code that
calls strptime.  To fix that, I had to use some macros in a sequence
like this:

#ifdef __CYGWIN__
/* Ensure that strptime is accessible. */
#define _XOPEN_SOURCE
#endif

#include <stdint.h>
...
#ifndef __CYGWIN__
/* Ensure that strptime is accessible. */
#define __USE_XOPEN
#endif

#include <time.h>


That seems to be the simplest I can make that.

Thank you to all the Cygwin developers who made this porting effort
possible!


-- Patrick

Re: setrlimit always fails

[Corinna Vinschen]

On Feb 12 10:11, Patrick Chkoreff wrote:
> Ken Brown via Cygwin wrote on 2/11/21 9:06 PM:
> 
> > Cygwin's setrlimit only supports a few resources, as you can see in the
> > source:
> > 
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/resource.cc;h=97777e9d223466b7635b990d6c9e0bfb9e2e9a46;hb=HEAD#l201
> [...]
> I will say that my first attempt at compiling the Linux code under
> Cygwin went very well.  The only compiler error was in some code that
> calls strptime.  To fix that, I had to use some macros in a sequence
> like this:
> 
> #ifdef __CYGWIN__
> /* Ensure that strptime is accessible. */
> #define _XOPEN_SOURCE
> #endif
> 
> #include <stdint.h>
> ...
> #ifndef __CYGWIN__
> /* Ensure that strptime is accessible. */
> #define __USE_XOPEN
> #endif
> 
> #include <time.h>
> 
> 
> That seems to be the simplest I can make that.

That looks wrong.  The __USE_<standard> flags are internal flags from
GLibc and not supposed to be used by application code.  Check the Linux
man page for strptime, the usage of _XOPEN_SOURCE or another flag
including _XOPEN_SOURCE (e. g. _GNU_SOURCE) is required.  So this:

  #define _XOPEN_SOURCE
  #include <time.h>

should be sufficient.


Corinna

Re: setrlimit always fails

[Patrick Chkoreff]

Corinna Vinschen wrote on 2/15/21 4:14 AM:

> That looks wrong.  The __USE_<standard> flags are internal flags from
> GLibc and not supposed to be used by application code.  Check the Linux
> man page for strptime, the usage of _XOPEN_SOURCE or another flag
> including _XOPEN_SOURCE (e. g. _GNU_SOURCE) is required.  So this:
> 
>   #define _XOPEN_SOURCE
>   #include <time.h>

One would think so, but I tried it on two different Linux machines and
it failed with:

error: ‘strptime’ undeclared

To fix that, I must define _USE_XOPEN.

I have stripped down my requirements as far as possible.  I created a
file "test_stuff.c" as follows, with the most minimal preambles that
actually work on each platform (Cygwin or Linux):

~~
#ifdef __CYGWIN__

#define _XOPEN_SOURCE
#include <stdint.h>
#include <sys/time.h>
#include <time.h>

#else

#include <stdint.h>
#include <sys/time.h>
#define __USE_XOPEN
#include <time.h>

#endif

void stuff(void)
    {
    uint64_t n;
    time_t t;
    struct timeval tv;
    (void)n;
    (void)t;
    (void)tv;
    (void)time;
    (void)gettimeofday;
    (void)timegm;
    (void)timelocal;
    (void)gmtime;
    (void)localtime;
    (void)strftime;
    (void)strptime;
    }

~~


That compiles successfully on both Cygwin and Linux, using the simple
command "gcc -c test_stuff.c".

Note that in the case of Linux, the define __USE_XOPEN is absolutely
essential, and define _XOPEN_SOURCE makes no difference.  This is an
experimental fact on the two Linux machines I tested.

Note also that on Cygwin, I must define _XOPEN_SOURCE before including
stdint.h.  There are all kinds of weird interactions and different
ordering requirements between the Linux and Cygwin code.  So let's look
at some options, and show how they work on both Linux and Cygwin.

OPTION 1:

#define _XOPEN_SOURCE
#include <stdint.h>
#include <sys/time.h>
#include <time.h>

Result on Cygwin: SUCCESS

Result on Linux:
error: ‘timegm’ undeclared
error: ‘timelocal’ undeclared


OPTION 2:

#include <stdint.h>
#include <sys/time.h>
#define _XOPEN_SOURCE
#include <time.h>

Result on Cygwin:
error: 'strptime' undeclared

Result on Linux:
error: 'strptime' undeclared


OPTION 3:

#include <stdint.h>
#include <sys/time.h>
#define __USE_XOPEN
#define _XOPEN_SOURCE
#include <time.h>

Result on Cygwin:
error: 'strptime' undeclared

Result on Linux:  SUCCESS


Consequently I see nothing simpler than the test_stuff.c code at the top
of this email.  By all means correct me if I am wrong.  Propose a
preamble on this list, and I'll jam it into my test code and see if it
compiles on both Cygwin and Linux.  I can literally compile the exact
same code file on both Cygwin and Linux, due to how I've got sharing set up.


-- Patrick

Re: setrlimit always fails

[Corinna Vinschen]

On Feb 15 14:54, Patrick Chkoreff wrote:
> Corinna Vinschen wrote on 2/15/21 4:14 AM:
> 
> > That looks wrong.  The __USE_<standard> flags are internal flags from
> > GLibc and not supposed to be used by application code.  Check the Linux
> > man page for strptime, the usage of _XOPEN_SOURCE or another flag
> > including _XOPEN_SOURCE (e. g. _GNU_SOURCE) is required.  So this:
> > 
> >   #define _XOPEN_SOURCE
> >   #include <time.h>
> 
> One would think so, but I tried it on two different Linux machines and
> it failed with:
> 
> error: ‘strptime’ undeclared
> 
> To fix that, I must define _USE_XOPEN

You really, really must not use this macro.

> #else
> 
> #include <stdint.h>
> #include <sys/time.h>
> #define __USE_XOPEN
> #include <time.h>
> 
> #endif
> 
> void stuff(void)
>     {
>     uint64_t n;
>     time_t t;
>     struct timeval tv;
>     (void)n;
>     (void)t;
>     (void)tv;
>     (void)time;
>     (void)gettimeofday;
>     (void)timegm;
>     (void)timelocal;
>     (void)gmtime;
>     (void)localtime;
>     (void)strftime;
>     (void)strptime;
>     }

The problem here is that you mix functions only defined under
_XOPEN_SOURCE with stuff only defined with _DEFAULT_SOURCE from the same
header.  Either define both feature test macros, or define _GNU_SOURCE.

This works:

#define _XOPEN_SOURCE
#define _DEFAULT_SOURCE
#include <stdint.h>
#include <sys/time.h>
#include <time.h>
void stuff(void)
[...]

This works, too:

#define _GNU_SOURCE
#include <stdint.h>
#include <sys/time.h>
#include <time.h>
void stuff(void)
[...]


Corinna

Re: setrlimit always fails

[Patrick Chkoreff]

Corinna Vinschen wrote on 2/15/21 3:48 PM:

> On Feb 15 14:54, Patrick Chkoreff wrote:
>> Corinna Vinschen wrote on 2/15/21 4:14 AM:
>> To fix that, I must define _USE_XOPEN
> 
> You really, really must not use this macro.

I'm glad to hear something definitive about that.  I don't even remember
how I arrived at that hack.


...
> The problem here is that you mix functions only defined under
> _XOPEN_SOURCE with stuff only defined with _DEFAULT_SOURCE from the same
> header.  Either define both feature test macros, or define _GNU_SOURCE.

Thank you for the sensible explanation.


> This works:
> 
> #define _XOPEN_SOURCE
> #define _DEFAULT_SOURCE
> #include <stdint.h>
> #include <sys/time.h>
> #include <time.h>
> void stuff(void)
> [...]

Yes, that does work on both Cygwin and Linux.


> This works, too:
> 
> #define _GNU_SOURCE
> #include <stdint.h>
> #include <sys/time.h>
> #include <time.h>
> void stuff(void)
> [...]

Yes, that also works on both Cygwin and Linux.

Thank you!


-- Patrick

Re: setrlimit always fails

[Marco Atzeri]

On 16.02.2021 15:53, Patrick Chkoreff wrote:
> Corinna Vinschen wrote on 2/15/21 3:48 PM:
> 
>> On Feb 15 14:54, Patrick Chkoreff wrote:
>>> Corinna Vinschen wrote on 2/15/21 4:14 AM:
>>> To fix that, I must define _USE_XOPEN
>>
>> You really, really must not use this macro.
> 
> I'm glad to hear something definitive about that.  I don't even remember
> how I arrived at that hack.

FYI

/usr/include/sys/features.h

provides the full framework for the different options

Regards
Marco

Re: setrlimit always fails

[Brian Inglis]

On 2021-02-16 08:22, Marco Atzeri via Cygwin wrote:
> On 16.02.2021 15:53, Patrick Chkoreff wrote:
>> Corinna Vinschen wrote on 2/15/21 3:48 PM:
>>
>>> On Feb 15 14:54, Patrick Chkoreff wrote:
>>>> Corinna Vinschen wrote on 2/15/21 4:14 AM:
>>>> To fix that, I must define _USE_XOPEN
>>>
>>> You really, really must not use this macro.
>>
>> I'm glad to hear something definitive about that.  I don't even remember
>> how I arrived at that hack.
> 
> FYI
> 
> /usr/include/sys/features.h
> 
> provides the full framework for the different options

Define both to allow everything:

_DEFAULT_SOURCE enables BSD and SysV features, is the default if *NO* others 
defined, and replaces old _BSD_SOURCE and/or _SVID_SOURCE
_GNU_SOURCE enables all the GNU, X/Open, POSIX, C, etc. features but original 
Unix SysV and BSD extensions

Search online for man 7 feature_test_macros, copy from a Linux system, or 
download, and install the man page under /usr/local/man/man7/ for reference.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: setrlimit always fails

[Corinna Vinschen]

On Feb 11 10:23, Patrick Chkoreff wrote:
> I'm trying to use setrlimit to impose limits on various resources such
> as CPU time and memory.  The call to setrlimit always fails.  I've
> distilled this into the following example test.c:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/resource.h>
> 
> int main(void)
>     {
>     struct rlimit rlim;
>     rlim.rlim_cur = 1;
>     rlim.rlim_max = 1;
>     if (setrlimit(RLIMIT_CPU,&rlim) < 0)
>         {
>         perror("setrlimit");
>         exit(1);
>         }
>     printf("HEY\n");
>     while (1)
>         {
>         }
>     printf("BYE\n");
>     return 0;
>     }
> 
> $ gcc test.c
> $ ./a.exe
> setrlimit: Invalid argument
> 
> 
> I have found that the only way to make the setrlimit call succeed is to
> use RLIM_INFINITY:
> 
>     rlim.rlim_cur = RLIM_INFINITY;
>     rlim.rlim_max = RLIM_INFINITY;
> 
> But then of course it does not achieve the desired result of timing out
> after 1 second.
> 
> Any ideas?

Most of setrlimit is not supported.  There's a bit of RLIMIT_CORE
and RLIMIT_NOFILE support but it's basically fake because Windows
doesn't (or didn't in some cases) have support for setting limits
for the own and child processes.


Corinna