setrlimit fails with Operation not permitted when run under valgrind

Of the allowed range of fd 0 .. hard_limit,valgrind reserves a set of fd for its own purposes at the end of the rangei.e. the range hard_limit - 11 .. hard_limit,and then simulates a new hard limit which is hard_limit - 12.

It then forbids the guest application to change this (simulated) hard limit.Here is the piece of code that handles the setrlimit simulation:

 if (((struct vki_rlimit *)(Addr)ARG2)->rlim_cur > VG_(fd_hard_limit) ||      ((struct vki_rlimit *)(Addr)ARG2)->rlim_max != VG_(fd_hard_limit)) {     SET_STATUS_Failure( VKI_EPERM );  }

As you can see, if the provided rlim_max is different of the simulated VG_(fd_hard_limit), valgrind makes the setrlimit fails.When accepted, valgrind will change the simulated soft limit.

I am not too sure to understand why the above code does notaccept a lower hard limit and set it into the simulated VG_(fd_hard_limit).I think it is because this (not changeable) VG_(fd_hard_limit) is usedby valgrind to find the difference between the valgrind reserved fds andthe guest fds.

To bypass the problem, you should get the limit, and then only changethe soft limit below the hard limit as changing the hard limit willbe rejected by the valgrind setrlimit simulation.

It seems that this is one of the limitations of Valgrind, namely a limitation of setrlimit for hard limit when run under Valgrind. See in news for release 2.1.2:

• Implement an emulated soft limit for file descriptors in addition to the current reserved area, which effectively acts as a hard limit. The setrlimit system call now simply updates the emulated limits as best as possible - the hard limit is not allowed to move at all and just returns EPERM if you try and change it. This should stop reductions in the soft limit causing assertions when valgrind tries to allocate descriptors from the reserved area. (This actually came from bug #83998).

Note that you are not the only one who hit this Valgrind limitation, see this github issue for example.