{"action":"opened","issue":{"url":"https://api.github.com/repos/boostorg/asio/issues/168","repository_url":"https://api.github.com/repos/boostorg/asio","labels_url":"https://api.github.com/repos/boostorg/asio/issues/168/labels{/name}","comments_url":"https://api.github.com/repos/boostorg/asio/issues/168/comments","events_url":"https://api.github.com/repos/boostorg/asio/issues/168/events","html_url":"https://github.com/boostorg/asio/issues/168","id":382263183,"node_id":"MDU6SXNzdWUzODIyNjMxODM=","number":168,"title":"epoll_wait() returning too many file descriptors","user":{"login":"skysley","id":44500899,"node_id":"MDQ6VXNlcjQ0NTAwODk5","avatar_url":"https://avatars3.githubusercontent.com/u/44500899?v=4","gravatar_id":"","url":"https://api.github.com/users/skysley","html_url":"https://github.com/skysley","followers_url":"https://api.github.com/users/skysley/followers","following_url":"https://api.github.com/users/skysley/following{/other_user}","gists_url":"https://api.github.com/users/skysley/gists{/gist_id}","starred_url":"https://api.github.com/users/skysley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/skysley/subscriptions","organizations_url":"https://api.github.com/users/skysley/orgs","repos_url":"https://api.github.com/users/skysley/repos","events_url":"https://api.github.com/users/skysley/events{/privacy}","received_events_url":"https://api.github.com/users/skysley/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-11-19T15:21:50Z","updated_at":"2018-11-19T15:21:50Z","closed_at":null,"author_association":"NONE","body":"Hi,\r\nI am not sure whether the root cause is in the boost::asio or in the implementation of epoll_wait(). However, it may be good to handle the case described below. I am using boost 1.67.0.\r\n \r\nI have a program which spawns a lot of sub-processes and a lot of threads. Communication is basically done via boost's signals and slots and via boost::interprocess::message_queue. While I was looking for a memory leak, I encountered a strange behavior. In epoll_reactor.ipp within epoll_reactor::run() one can find this code:\r\n\r\n```C++\r\n  epoll_event events[128];\r\n  int num_events = epoll_wait(epoll_fd_, events, 128, timeout);\r\n```\r\n\r\nThe number of file descriptors should be limited to 128. However, I encountered ```num_events``` to be 232 (see attached screenshot). Until now, I haven't got an idea why this happens. However, it would be helpful if it would be checked (at least via an assertion) that ```nume_events``` is not larger than 128.\r\n\r\n[backtrace.txt](https://github.com/boostorg/asio/files/2595844/backtrace.txt)\r\n\r\nScreenshot:\r\n![epoll_wait_result](https://user-images.githubusercontent.com/44500899/48715877-538d3980-ec16-11e8-8488-78af039967bd.png)\r\n"}}
{"actor":{"display_login":"skysley"}}