As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached):
#include <stdio.h>
#include <sys/socket.h>
#include <string.h>
#include <unistd.h>
#include <sys/errno.h>
static int create_socket(const int attempt_number) {
const int fd = socket(AF_INET6, SOCK_STREAM, 0);
if (fd < 0) {
fprintf(stderr, "socket creation failed on attempt %d,"
" due to: %s\n", attempt_number, strerror(errno));
return fd;
}
return fd;
}
int main() {
const unsigned int num_times = 250000;
for (unsigned int i = 1; i <= num_times; i++) {
const int fd = create_socket(i);
if (fd < 0) {
return -1;
}
close(fd);
}
fprintf(stderr, "successfully created and closed %d sockets\n", num_times);
}
The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations.
Compiling this as:
clang sockbufspaceerr.c -o sockbufspaceerr.o
and running it as:
./sockbufspaceerr.o
consistently generates an error as follows on macos 26.x:
socket creation failed on attempt 160995, due to: No buffer space available
The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations.
Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x.
Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?
4
0
420