Re: [Boost-bugs] [Boost C++ Libraries] #7611: segfault in epoll_reactor.ipp

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7611: segfault in epoll_reactor.ipp
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2018-07-31 12:54:45

#7611: segfault in epoll_reactor.ipp
-------------------------------------------------+-------------------------
  Reporter:  Fredrik Jansson                     |      Owner:
  <fredrik.jansson.se@…>                         |  chris_kohlhoff
      Type:  Bugs                                |     Status:  reopened
 Milestone:  To Be Determined                    |  Component:  asio
   Version:  Boost 1.52.0                        |   Severity:  Problem
Resolution:                                      |   Keywords:
-------------------------------------------------+-------------------------

Comment (by anonymous):

 Replying to [comment:2 chris_kohlhoff]:
 > The descriptor_data variable is only set to NULL when the corresponding
 socket is deregistered (see epoll_reactor::deregister_descriptor, which is
 in turn called from reactive_socket_service_base::destroy/close). This
 means that your program has closed the socket or destroyed the socket
 object.
 >
 > Most likely you have a threading issue in your program where you close a
 socket from one thread while simultaneously starting another async
 operation on the same socket from another thread. If you are sure this is
 not the case, please attach a small, complete program that exhibits the
 problem. Thanks.

 Hi all,
 I'm using boost asio 1.67.0 in a quite big application. It is a webrtc
 server that uses both tcp and
 udp sockets to forward data among users.

 The server can run both on windows or linux.

 And I have the same issue reported above on linux only. On windows it
 works fine.

 It is difficult to reproduce, but I found a scenario that works using
 valgrind.

 The threading model I'm using is one io_service, multiple threads.

 The behavior of the application in the point near the crash is the
 following:
 when the tcp socket of the user disconnects, then the server closes the
 udp socket and finalizes the session for that user.

 The crash happens (sometimes) closing the udp socket while it is
 reading/writing.

 Following you suggestion I wrapped all async operations of
 read/write/close in the same strand (one per udp socket) and magically it
 stopped crashing.

 Before this, the strand was used only to serialize the write operations
 and avoid unordered transmission of packets. Because the read_async is
 called after the processing of the previous data chunk.

 I checked the release notes of the previous versions of boost and it seems
 that the problem has been fixed into 1.65.0:
 Fixed a race condition in the Linux epoll backend, which may occur when a
 socket or descriptor is closed while another thread is blocked on epoll.

 But it is not.

 For what I understood about asio, it should be possible to read and write
 on the same socket from different threads without any problem. But if the
 close requires serialization, then all read/ write operations must be
 wrapped by a strand. And it will affect the performance (a bit).

 Is this a bug inside the epoll/linux implementation of asio sockets or is
 it the correct way of working and it must be managed by the application?

 Thank you,
 let me know if I can do something to help to solve.

 Emanuele

-- 
Ticket URL: <https://svn.boost.org/trac10/ticket/7611#comment:15>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.