wwade
commented
4 years ago I think you missed my comment about having, potentially, the wrong notion of a specific RLIMIT_ value.
It's possible the enum BST_ does not reflect reality and so we try to set nproc and end up with core.
On Fri., Sep. 11, 2020, 6:51 a.m. Franklin Mathieu, < notifications@github.com> wrote:
@Snaipe commented on this pull request.
In bst_limits.c https://github.com/aristanetworks/bst/pull/33#discussion_r487058836:
- if ((uintmax_t)parse_val >= RLIM_INFINITY) {
- if ((uintmax_t)parse_val >= BST_RLIM_INFINITY) {
If we're passing nonsense to setrlimit, we'll just get EINVAL and abort, which seems right. Syscall interfaces (apart from actual syscall numbers and intptr sizes between 32 and 64-bit) are fairly stable across platforms, so our definition of RLIM_INFINITY should hold fairly well. It's basically -1.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aristanetworks/bst/pull/33#discussion_r487058836, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATU5OH5K2JQETTKISDIQWDSFITN3ANCNFSM4RFPLFSA .
The limit parsing logic now always calls getrlimit and only stomps on the current value if it was actually specified. I also simplified the pointer+limit storage logic in the entry structure, which seems to have made the crashes go away.