Open ravinrabbid opened 10 months ago
Hi, is it possible for you to switch to 1.4(rc) branch? Epoll is already implemented there for the event loop, that no longer has the limitations on Linux based systems. This would also bring further advantages in terms of processing speed.
Otherwise it would be possible to switch from select to poll. However, this is associated with some effort and I'm not sure whether the limitation of fd set size is kind of an exceptional case and is therefore more likely to be addressed with a lower priority.
Thanks for your reply! We've indeed already patched the parts we need for our use-case to use poll() instead.
Good to know that this is already addressed for 1.4, it still might be worth looking into at least checking the file descriptor against FD_SETSIZE
for 1.3 and provide an error. While there are probably not that many people running into this, problems caused by this can be very unspecific and hard to debug.
We can integrate a patch to 1.3 if It is provided. And small enough that we can exclude new bugs being introduced.
The change in 1.4 has been quit extensive under the hood. The effort from the maintainers goes to the “new reality” that already supports epoll.
Description
open62541 as of version 1.3.8 uses
select()
to wait on sockets which is limited to file descriptors <1024 on Linux. In larger scale applications where file descriptors are likely to grow larger, this leads to undefined behavior and crashes.Background Information / Reproduction Steps
To reproduce, open a lot of file descriptors (>1024) before opening a client connection with open62541. You might need to increase the limit for open files on your system first. The application will cause a segmentation fault upon connection.
This is because the behavior for
FD_SET
is undefined for fds >=FD_SETSIZE
on Linux, which in practice will lead to stack corruption.Excerpt of the core dump
Used CMake options:
Checklist
Please provide the following information:
v1.3.8
UA_LOGLEVEL
set as low as necessary) attached