Unexplained behavioural changes in BSD sockets on macos 26.6.x and 27

I don’t think there’s anything I can do to help out here:

• Regarding bug priority, the network engineer team sets its own priorities based on a lot of competing demands on its time from a lot of different folks.
• Regarding Darwin source drops, historically Apple has released Darwin source shortly after the corresponding macOS release, but there’s no concrete timeline for this.

So, while I’m happy to look at specific API-level problems, there are limits to what I can do about the big picture.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello Quinn,

Regarding bug priority, the network engineer team sets its own priorities based on a lot of competing demands on its time from a lot of different folks.

Just to clarify my previous post, the priority and how long it takes to fix the issue isn't the demotivating part. I understand that it might take long to fix those reported issues. The demotivating part is that several of these issues that are reported in the feedback assistant don't receive any response at all. There's complete silence on them even for trivial questions like reproducibility of the issue. Given the frequency with which these behavioural changes are happening in these APIs, we have been putting in much more efforts to test beta versions of macos releases so that these issues can be reported early (we aren't fully there yet, but such testing has increased). But reporting such issues and not seeing any response or an acknowledgement to them feels like it's defeating the purpose of this extended testing. The OpenJDK testsuite is vast and we often catch such issues with newer releases of macos. My hope is that there will be a bit more involvement when such issues are reported through feedback assistant.

Regarding Darwin source drops, historically Apple has released Darwin source shortly after the corresponding macOS release, but there’s no concrete timeline for this.

Right, and that adds to the challenge of understanding what's changed or how to properly address those changes within the application code (because the release notes too don't have any details). So when some issue shows up in a new release, we end up spending large amounts of time (sometimes months) mostly guessing what might have changed without anything concrete to go on.

there are limits to what I can do about the big picture.

I understand. I am thankful for all the help I receive from you and others in these forums. In fact, that's one of the reasons why I still have the motivation left to dig deeper in these issues and report them.

So I want to maintain a list of these kinds of issues you’ve reported, primarily just for my own bookkeeping. Here’s a start:

• FB25031577 from macos 27 - EDOM error from setsockopt() for SO_LINGER socket option for values greater than 32767
• FB25031051 and FB25031272 from macos 27 - unexpected/new errno from BSD socket connect() when pending connections exceed backlog
• FB25019064 from Out-of-band data returned by recv() and read() on socket bound to non-loopback address even when SO_OOBINLINE is disabled
• FB12128351 from UDP socket bind with ephemeral port on macos results in OS allocating a already bound/in-use port

Lemme know if there’s anything I missed.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Revision History

• 2026-09-06 Added FB12128351.
• 2026-09-05 First posted.

Hello Quinn,

Yes, these are the current ones that impact 27.x. I am reviewing some others and will report back if they turn out to be something that needs attention.

One other issue which is certainly a change in macos, is in the ptrace area where after successfully attaching (PT_ATTACHEXC) to a process and then successfully detaching from that process (PT_DETACH), the target process continues to be in stopped state (if I am not wrong, then SSTOP state) and thus becomes unresponsive to any work that is expected of it. This has been observed in 26.6.x and 27.x of macos (including 27.2 beta release). So something has changed here, but not clear what or whether it's a bug in macos. There's a bit more technical details involved here and it's not easy (yet) to try and make it simpler to reproduce. However, for people familiar with this area of ptrace, Mach tasks and signals, then maybe the current discussion in OpenJDK PR which tries to fix the issue might provide the necessary context https://github.com/openjdk/jdk/pull/33158.

I was hoping the kernel sources for 26.6.x and 27.x, when they are available, might provide some guidance on what the right fix is for this (even if in application code). The documentation in this area is hard to find except for this (nicely written) decade old blog https://www.spaceflint.com/?p=150

I’ve been zenning on the wider issue over the past few days and I’ve had an Idea™ (-:

It’s clear that your test suite is really good and finding corner cases in our ‘behaves like a Unix-y system’ story. Given that, it’d be cool if we ran it internally, with the goal of finding and fixing such problems before we start seeding. Do you think that’s feasible? [1]

If so, I’d appreciate you filing a enhancement request for just that [2]. I can’t make any promises here — at this point this is just my own off-the-wall idea — but it’s worth a short.

Once you’re done, reply here with your bug number so I can add my own (internal) comments to it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Considering things like:

• All the code is open source
• Under a reasonable licence
• And doesn’t require any particularly onerous setup

[2] Make sure to include some basic info, covering the sorts of points that I raised in the previous footnote.