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?
Once you’re done, please post your bug number, just for the record.
Thank you Quinn, I've now filed FB21686886.
And thanks, as always, for your efforts here. Your test suite is certainly doing its bit to keep us honest (-:
I'm happy to help :) The OpenJDK testsuite is indeed vast. One of our bigger challenges in recent times has been trying to get a resolution for several stability issues/regressions with BSD socket APIs on macos. I'm glad that these dev forums exist and there are knowledgeable engineers from Apple who regularly respond and provide help. That helps stay motivated to investigate these issues and report them. Feedback assistant tool on the other hand is a bit of a disappointment - lack of any response and visibility on the filed issues there for several months/years even for basic questions makes it a bigger challenge to take such reported issues to a proper resolution. Hopefully that tool/process will see some improvement in future.
Thanks again for the help.