Date: Fri, 26 Nov 2021 07:58:52 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 260055] recvmsg / IP_RECVDSTADDR issue Message-ID: <bug-260055-227-CFjxQQjiov@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-260055-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260055 --- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> --- The backtrace you reported is suspicious, pthread_suspend_all_np() cannot appear in the stack between _recvmg() and recvmsg(), most likely it is __thr_recvmsg() which was mis-identified due to missed debug symbols in libthr. Compile both libc and libthr with debug info. After that, first catch the kernel-side backtrace for the thread hung in recvmsg(). Next, show userspace backtraces from _all_ threads in the process. That said, GetSockDstAddress() is strange. From its name, it seems that the purpose of the function is to obtain the destination address, as the control message. But it also tries to read some data from the socket, and the data is discarded. If the socket is blocking, and there is no data, then it is expected for recvmsg(2) to block. Do you know what protocol type this socket is? [But this should be visible from the kernel stack]. Do you know if this socket is blocking? Also, why is it safe to discard the data? -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-260055-227-CFjxQQjiov>