Recvfrom null buffer returning errno EFAULT?

Question

I'm programming a UDP non-blocking socket and I have the function

void recvflush(int sockfd) {
  ssize_t num;
  while (errno != EWOULDBLOCK) {
    num = recvfrom(sockfd, NULL, maxpack, 0, NULL, NULL);
    if (num < 0 && errno != EWOULDBLOCK)
      error("recvfrom() failed", strerror(errno));
  }
}

to flush the receive buffer. However, it is returning EFAULT (Bad address) when I call it, and I make sure I have the sockfd set when I do. Help!

Thanks

Where'd you get the idea you could pass `NULL` as the second argument to `recvfrom()`? That's why it's crashing, because the OS can't write the received data to that "address". You'll probably have to allocate a local buffer (`char buf[1500];`) to read into, even though you're just going to throw the data away. — Steve Summit, Jul 12 '18 at 23:22
Come to think of it, since excess data (from packets too big to fit in the user-supplied buffer) is discarded, I guess you could get away with`char buf[1]`. — Steve Summit, Jul 12 '18 at 23:41

score 2 · Accepted Answer · answered Jul 12 '18 at 23:41

Is there some reason you expect that giving a NULL pointer to recvfrom will cause it to flush messages? You've told it your buffer is maxpack bytes long, but then you've given it an invalid pointer, so EFAULT is the correct and expected errno.

You should be able to supply a length of zero to discard a queued message: According to the recvfrom(2) man page, if the buffer length provided is too short for a message, the remaining data bytes will be discarded; that should include discarding of all the bytes.

Now, once you have provided a length of zero, you could also supply a NULL pointer since there is no requirement for any portion of the buffer to be valid in that case. But that is not because NULL pointer is specially recognized but because the provided length requires no part of it to point to valid memory.

Ah, okay. Great answer, that sounds perfect. I just thought I might as well keep the `maxpack` bytes as a parameter because I set it as a global anyways for the signal handler. I thought of putting 0 but I was a bit skeptical at first. Thanks! — Jonathan Lee, Jul 13 '18 at 13:10

Remy Lebeau · Answer 2 · 2018-07-13T17:01:49.713

Per the man page for recvfrom(), EFAULT is reported when:

EFAULT
The receive buffer pointer(s) point outside the process's address space.

Assuming your maxpack variable is > 0, recvfrom() is expecting to be able to write bytes to the buffer pointed to by the buf parameter, but you are passing NULL for that parameter, hence the error.

Why are you checking errno before calling recvfrom()? You should be calling recvfrom() first, and THEN check for an error. And stop looping when any error other than EWOULDBLOCK/EAGAIN, EINTR, or EMSGSIZE is reported.

Also, keep in mind that UDP supports 0-length packets, in which case recvfrom() would return 0 instead of -1, and errno would not be set. Make sure you account for that in your loop, too.

Try this instead:

void recvflush(int sockfd) {
  ssize_t num;
  do {
    num = recvfrom(sockfd, NULL, 0, 0, NULL, NULL);
    if (num < 0) {
      if ((errno == EWOULDBLOCK) || (errno == EAGAIN))
        break;
      if ((errno != EINTR) && (errno != EMSGSIZE)) {
        error("recvfrom() failed", strerror(errno));
        break;
      }
    }
  }
  while (true);
}

Or, if recvfrom() doesn't accept a 0-length buffer, then give it a small buffer to write into:

void recvflush(int sockfd) {
  ssize_t num;
  char c;
  do {
    num = recvfrom(sockfd, &c, 1, 0, NULL, NULL);
    if (num < 0) {
      if ((errno == EWOULDBLOCK) || (errno == EAGAIN))
        break;
      if ((errno != EINTR) && (errno != EMSGSIZE)) {
        error("recvfrom() failed", strerror(errno));
        break;
      }
    }
  }
  while (true);
}

Note that if your socket is NOT non-blocking, then EWOULDBLOCK/EAGAIN will not be reported since the call will block until data is available, so you should use select() or (e)poll() to check if the socket has any queued packets before entering the recvfrom() loop.

https://stackoverflow.com/questions/2178115/are-compilers-allowed-to-eliminate-infinite-loops/28681034#28681034, however your case is portable never mind (I think, infinite loop are so tricky sometime) — Stargateur, Jul 13 '18 at 04:26

Recvfrom null buffer returning errno EFAULT?

2 Answers2