Background: If accept() returns an error, QTcpServer may live lock. (QTBUG-24778) The problem as described is that accept() returns EMFILE when quota is reached. On returning to the event loop, select() triggers again because the incoming connection is still pending This prevents other sockets being handled because the server socket is always readable.
Proposal: Add a new signal QTcpServer::acceptError When the socket engine's accept() returns an error, the QTcpServer disables read notifications and emits the error signal. Add a new function void QTcpServer::resumeAccepting() The application can call this to restart the server (e.g. after a client disconnects) Add a new function void QTcpServer::pauseAccepting() This allows the application to manually suspend processing of incoming connections. See https://codereview.qt-project.org/28526 Backward compatibility: It doesn't need to be "opt in", because where this situation occurs previously the application would live lock and need to be closed or killed. 5.0 vs 5.1: The issue seems like it should be rare under normal circumstances. (Qt is not a toolkit for high load servers, and the default quota is ~1k file descriptors) However the consequences are severe. It's also a "denial of service" vulnerability, mitigated by the fact that QTcpServer only accepts 30 connections without application interaction (by default) -- ________________________________ Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
