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

Question

Created 3d

Replies 2

Boosts 0

Participants 2

We have started seeing some unexplained behavioural differences in the BSD socket APIs on macos 26.6.x and macos 27. On a different front, there also seems to be some changes in the ptrace area for PT_DETACH. Historically, the release notes of macos don't include any mention of such changes. And unfortunately, prior experience of filing feedback assistant issues too hasn't been very motivating due to lack of any response on those tickets.

These forums have been very helpful in trying to understand some of these changes, and I plan to raise separate topics for the issues shortly. In the past, the other useful option I have used is reading up the kernel sources published at https://opensource.apple.com/releases/. But there hasn't been any updates for macos 26.6 or macos 27.

It will be very useful if macos 26.6 and 27 releases are published there. That will help expedite investigating some of these failures.

BSD socket APIs in the recent releases of macos have seen several issues (feedback assistant issues have been filed). The implications of these failures is that we (in OpenJDK) have had to disable several tests on recent versions of macos which has reduced the test coverage and reliability of these very primitive networking APIs on this platform.

Answered by DTS Engineer in 907567022

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"

Answer 1

DTS Engineer OP

Apple

3d

Recommended

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"

Answer 2

jaikiran OP

3d

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.