Are you extracting a fd from a libuv object then calling close or uv_poll on it? Either would cause problems, and shouldn't be done.
On Sun, May 9, 2021 at 2:53 PM Jameson Nash <vtjn...@gmail.com> wrote: > uv_poll_stop and uv_accept must happen on the same thread, so how are they > racing? Once uv_poll_stop is called, it should be safe to notify another > thread to call close, even if that then happens concurrently, as the kernel > should be thread-safe (though weird things may happen in userspace if you > close a fd that is concurrently in use on another thread or event queue). > > On Sun, May 9, 2021 at 1:24 PM Paul Romero <pa...@rcom-software.com> > wrote: > >> Hi: >> >> Using TSAN did turn up one very signifcant problem. The root cause of the >> TCP socket descriptor corrpution >> is that accept4() executes concurrently in the main() task, with close() >> in the Protocol_Task(). >> >> As an interim measure I avoid the problem by simply not calling close(). >> So far this has worked >> seemlesly and Libuv appears to automatically free socket descriptors. The >> Libuv documentation >> about this is somewhat ambiguous. It indicates that after calling >> uv_poll_stop() or uv_close(), >> for a particular uv_poll_t poll handle, the socket descriptor is returned >> to the user per the Libuv >> contract. I am not sure what that means, and in particular, if it means >> the socket descriptor is freed. >> Can you clarify this ? >> >> A tagential issue is whether Linux accept4() and close() are thread safe. >> I believe they >> are and the crucial data is protected in the kernel. Is it possible Libuv >> is not handling the accept4() >> return codes correctly ? The Linux accept4() man page details how errors >> should be handled and is it >> somewhat fussy. The Linux close() man page also details error handling >> but it is straight forward. >> >> Also, I haven't been able to make the program compiled with TSAN dump >> core. Do you have >> any suggestions ? Incidentally, I had to use clang rather than the usual >> gcc to get >> TSAN to work on my system. >> >> Best Regards, >> >> Paul R. >> >> On 05/08/2021 08:51 AM, Jameson Nash wrote: >> >> Are you still accessing libuv (sans explicitly thread-safe functions such >> as uv_async_send) from multiple threads, as you mentioned earlier? If so, >> I'd suggest fixing that first. In conjunction, I recommend running TSan and >> making sure it runs cleanly before checking for library or logic problems. >> Then, if it is still a rare failure, I recommend debugging under `rr` as >> you'll be able to run forward to the problem, then walk backwards through >> the code to see what happened to your state and file descriptors. >> >> >> On Sat, May 8, 2021 at 11:27 AM pa...@rcom-software.com < >> pa...@rcom-software.com> wrote: >> >>> Hi: >>> >>> Addition to my last message. When uv__nonblock() fails it is indicative >>> of a Linux FIONBIO ioctl() failure. What would cause >>> setting non-blocking mode to fail ? >>> >>> Best Regards, >>> >>> Paul R. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "libuv" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to libuv+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> <https://groups.google.com/d/msgid/libuv/CADnnjUW6KL3OQw5C54aNfKh95z1OpQiq2bgVtXya8z_BeqMS9w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> https://groups.google.com/d/msgid/libuv/CADnnjUW6KL3OQw5C54aNfKh95z1OpQiq2bgVtXya8z_BeqMS9w%40mail.gmail.com >> . >> >> >> -- >> >> >> Paul Romero >> ----------- >> RCOM Communications Software >> EMAIL: pa...@rcom-software.com >> PHONE: (510)482-2769 >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "libuv" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to libuv+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/libuv/60981AE7.3000809%40rcom-software.com >> <https://groups.google.com/d/msgid/libuv/60981AE7.3000809%40rcom-software.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/libuv/CADnnjUWfszx9K8FdGPwGD%3D_5C0s1QVrDkaJD2ML2%3DEygefFD_A%40mail.gmail.com.
