On 08/01/2016 12:08 PM, Christian Seiler wrote: > Problem 1 (causing SIGLOST): > > When msg_name and msg_namelen are filled for a SOCK_STREAM AF_LOCAL > socket (maybe also other AF_LOCAL, didn't check) upon calling > recvmsg, SIGLOST is generated.
So this is actually a bug in glibc, in that recvmsg (in contrast to recvfrom) doesn't properly handle the case when __recv returns MACH_PORT_NULL as the source port (which is the case when using PF_LOCAL). I've attached a trivial patch that fixes this issue. I've reported this to the glibc bugtracker: https://sourceware.org/bugzilla/show_bug.cgi?id=20444 Regards, Christian
Description: [hurd] recvmsg: don't try to resolve invalid address Hurd's PF_LOCAL implementation doesn't return an address when calling __recv. recvmsg wasn't catching that and tried to call __socket_whatis_address on MACH_PORT_NULL, causing Hurd to send SIGLOST to the process. Properly handle this, analogously to how recvfrom does it. Author: Christian Seiler <christ...@iwakd.de> Bug: https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00000.html Last-Update: 2016-08-05 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/sysdeps/mach/hurd/recvmsg.c +++ b/sysdeps/mach/hurd/recvmsg.c @@ -202,7 +202,7 @@ __libc_recvmsg (int fd, struct msghdr *m &message->msg_flags, amount))) return __hurd_sockfail (fd, flags, err); - if (message->msg_name != NULL) + if (message->msg_name != NULL && aport != MACH_PORT_NULL) { char *buf = message->msg_name; mach_msg_type_number_t buflen = message->msg_namelen; @@ -236,6 +236,8 @@ __libc_recvmsg (int fd, struct msghdr *m if (buflen > 0) ((struct sockaddr *) message->msg_name)->sa_family = type; } + else if (message->msg_name != NULL) + message->msg_namelen = 0; __mach_port_deallocate (__mach_task_self (), aport);