[jira] [Created] (THRIFT-5677) lib: cpp: transport: file descriptor leak in TServerSocket::close()

["Christopher Friedt (Jira)" <ji...@apache.org>]

Christopher Friedt created THRIFT-5677:
------------------------------------------

             Summary: lib: cpp: transport: file descriptor leak in TServerSocket::close()
                 Key: THRIFT-5677
                 URL: https://issues.apache.org/jira/browse/THRIFT-5677
             Project: Thrift
          Issue Type: Bug
          Components: C++ - Library
    Affects Versions: 0.17.0, 0.16.0, 0.14.2, 0.14.1, 0.15.0, 0.14.0, 0.13.0, 0.12.0
         Environment: See description above.
            Reporter: Christopher Friedt
         Attachments: socketpair_close_fcntl_test.c, thrift-zephyr-tsocketserver-close-fd-fixed.txt, thrift-zephyr-tsocketserver-close-fd-leak.patch, thrift-zephyr-tsocketserver-close-fd-leak.txt

It would appear that there is a possible file descriptor leak in TServerSocket.cpp

This was discovered in the final stages of porting Thrift to the Zephyr RTOS.

In the context of integration testing with the ThriftTest.thrift sample, and specifically for the TSSLServerSocket, I was able to isolate the file descriptor leak to TServerSocket::close() with some basic printk debugging. Specifically, pChildInterruptSockReader_.reset() is called without first closing a possible underlying file descriptor.

As an IoT / microcontroller RTOS, Zephyr typically runs on devices with very little in the way of resources (RAM, ROM, CPU frequency, etc). Like everything else, Zephyr's POSIX subsystem has a limit on the maximum number of open file descriptors.

On large-scale operating systems, leaked file descriptors may be garbage collected after some time (certainly when a process dies). However, on RTOSes, that may not be the case.

It's possible that there was some assumption made about socketpair() and whether closing one side of the socketpair closes the other. It does not, and there is no stipulation anywhere in the POSIX standard that says that is the case. To validate that, I wrote a small test for POSIX systems (attached) and verified that it supports the aforementioned on both Linux and macOS. As the POSIX subsystem maintainer for Zephyr and author of Zephyr's socketpair() implementation, I am intimately familiar with the nuances of socketpair() and related POSIX API.

It would appear that this regression was introduced in commit 1684c429501e9df9387cb518e660691f032d7926 in 2015.

*THIS SHOULD PROBABLY BE PATCHED ASAP AS THRIFT IS TO BE INCLUDED IN ZEPHYRS V3.3 RELEASE*

CC [~jensg] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)