util: check integer overrun in RaiseFileDescriptorLimit #21434

The function RaiseFileDescriptorLimit returns an integer, but the returned value limitFD.rlim_cur (rlim_t) can be of type unsigned long long in some systems. This can lead to an overrun and subsequently to an error in the calling functions. To prevent that, it has to be checked if the value of rlim_cur exceeds the integer boundaries. If so the rlim_cur will be set to the maximum integer value.

Warm welcome as a contributor @sebastianrapp!

Interesting find! Can you describe how to reproduce the issue locally (what OS, what commands to issue, etc.)?

May I ask how you found this issue? It is always interesting to know.

Thank you very much. I was using macOS Big Sur (version 11.2.1) to reproduce this issue. Here I just need to run bitcoind and got the error message "Init: Not enough file descriptors available." So to be honest I was wondering why this issues was not observed before as this is a pretty straightforward use case, right. So maybe I have any special setting in my system of which I am currently not aware.

I don't have any Mac around to test on unfortunately: anyone running macOS who is able to reproduce this?

It is kind of strange, as functions such as open read write return or take an int >= 0 there would be no possible reason for there ever to be more than 2**31 file descriptors, so I cannot see the rationale of using a larger type for the limit. That said if this is necessary on some platforms it's necessary.

Edit: well strictly if you want to use file descriptor 0x7fff_ffff you do need a type that can represent 0x8000_0000 which is > int … using that one extra fd doesn't seem worth the potential edge cases introduced by making this function return a different type though :smile:

So maybe I have any special setting in my system of which I am currently not aware.

Given this is clearly something that no-one else is running into (there are many developers and users running bitcoind on macOS), I don't think we are going to merge this as-is. Probably a long-shot, but if you can provide any further information that may make it clearer as to why it's happening on your system, we could follow up. However I'm going to close this PR for now.