Hello Quinn, I don't have data on whether applications still rely on out-of-band or whether applications do send out-of-band data. However, given that this is an option at the socket level, the JDK as part of the Java specification exposes an API on its java.net.Socket class to allow applications to enable or disable this option https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/Socket.html#setOOBInline(boolean). As part of verifying that the Java API works as expected (on all OS), we run tests for that API. In fact, that's what prompted me to look into this issue when we noticed it fail (only) on macos. For context, here's the JDK issue https://bugs.openjdk.org/browse/JDK-8279920 where we have been tracking this. Specifically here, if some peer ends up sending a out-of-band data (for whatever reason) and even if the application has decided it isn't interested in out-of-band data (which is the default), then the application can still end up receiving this out-of-band data unexpectedly.

@javadev12345, since you note that this happens with jpackage and is even reproducible with the recent released Java 20, I would recommend that you open an issue here https://bugreport.java.com/bugreport/start_form with all relevant details, including the commands that you use and whether this is a macos x64 or M1, so that someone from the jpackage team can take a look. I remember that in the past there was at least one similar issue which I think was addressed in https://bugs.openjdk.org/browse/JDK-8276150 and https://bugs.openjdk.org/browse/JDK-8277493. This could be a different variant of the issue though.

Hello Quinn, Having said that… We have a reproducer which consistenly shows this behaviour. You should definitely file a bug about this. Please post your bug number, just for the record. Thank you for your inputs. I've filed the feedback issue as suggested. The issue id is FB12128351

Hello enodev, How do you create/bind the socket? We use low level system calls, the udp4 socket creation/bind looks something like: fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { printf("Failed to open socket: %d\n", errno); return -1; } SOCKETADDRESS sa; memset((char *)&sa, 0, sizeof(SOCKETADDRESS)); sa.sa4.sin_family = AF_INET; sa.sa4.sin_port = 0; sa.sa4.sin_addr.s_addr = htonl(0x0); // bind to wildcard socklen_t len = sizeof(sa.sa4); int res; res = bind(fd, &sa.sa, len); if (res < 0) { printf("Failed to bind: %d\n", errno); return -2; } and the udp46 socket creation/bind looks similar except for the additional setsockopt call which we do to disable IPv6_ONLY on that socket: int fd; fd = socket(AF_INET6, SOCK_DGRAM, 0); if (fd < 0) { printf("Failed to open socket: %d\n", errno); return -1; } // mark it as dual socket int ipv6_only = 0; // dual socket if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &ipv6_only, sizeof(int)) < 0) { return -2; } SOCKETADDRESS sa; memset((char *)&sa, 0, sizeof(SOCKETADDRESS)); sa.sa6.sin6_family = AF_INET6; sa.sa6.sin6_port = 0; char caddr[16]; memset((char *)caddr, 0, 16); // wildcard memcpy((void *)&sa.sa6.sin6_addr, caddr, sizeof(struct in6_addr)); socklen_t len = sizeof(sa.sa6); int res; res = bind(fd, &sa.sa, len); if (res < 0) { printf("Failed to bind: %d\n", errno); return -3; } Both sockets above are owned by PID 89318, what PID is that? Please ignore that process id. As I noted in the original description this process id is the reproducer code that we ran to reproduce this issue. So in this case, the reproducer first creates a udp4 socket and binds it to an ephemeral port (and lets it stay bound till the program exits) and then creates udp46 socket and binds it to an ephemeral port. Occasionally (but consistently), this programs ends up with the already in-use port being assigned to the udp46 socket bind call. So in this case, the process ids are the same but in reality (and in production), the processes are different and unrelated (for example: we have noticed that one of our program when it binds a udp46 socket with ephemeral port, it gets assigned the port which is already in use by the system's syslogd process which has it bound to udp4)

Yeah, I just tried that myself and I’m having the same problem [1]. The good news is that things get rendered correctly on our side, both in Radar and our internal view of Feedback Assistant. Still, this is annoying and I encourage you to file a bug. Make sure to include screen shots of what the Safari window looked like just before you submitted the bug and how the bug gets rendered in the end. Hello Quinn, I've now submitted FB12022556 to track this rendering issue. I've attached relevant screenshots to that issue.

Just for the record, I wasn't able to get the debug symbols for the ksh shipped in macos. However, fortunately, this issue was reproducible even on upstream ksh, for which the source is available and I was able to reproduce it on that version. This was then reported and fixed in https://github.com/ksh93/ksh/issues/591. A feedback issue has also been filed with Apple so that this fix gets pulled in into Apple's version of ksh. Feedback id is FB11941810

Hello Quinn, thank you for taking a look at this. I've now filed FB12016446 with these details and also included a link to this discussion. On a related note, the feedback issue rendering(?) I think has an issue. Every time I submit some issue, the contents in the "Description" section has all its newlines trimmed. Even the current one I filed has this problem. So it just appears as a wall of text without any newlines. This has now happened for more than one feedback issue that I have submitted. I even provided this feedback on one of the issues, but I haven't seen any response or acknowledgment. Not sure if it's an issue with my browser (Safari) or something else. The first couple of feedback issues that I had filed (around an year back) didn't have this problem.

I notice that the Apple opensource release page https://opensource.apple.com/releases/ now has links to the relevant sources for Ventura. For xnu it points to https://github.com/apple-oss-distributions/xnu/tree/xnu-8792.41.9 (and also has a separate download link).

Thank you Quinn. I think, those source code links are a good starting place to understand what these values do.

The errno values usually show up in a sysdiagnose, if you take a look at the logarchive file around the time the issue took place. See the section under sysdiagnose here. @meaton, thank you very much for that input. That certainly helped in understanding one UDP related test failure on my local setup. The logarchive had a couple of lines of log messages which provided the necessary hint that there was a system level content filter extension which was getting involved in this flow and that was causing the unexpected odd failure. Dealing with the system level content filter extension to not interfere with this test, helped the test pass. Of course, there are several other tests that fail intermittently (and in some cases there's no content filter involved). So I'll will be reviewing those failures through these sysdiagnose data. Hopefully, I'll find the necessary data to narrow them down too. Thanks again.

Thank you for responding @meaton. What are the log messages that are written out during this time? Also are there any errno logs generated here? What I meant by the log message being written out was that the source code (the one I'm guessing is the right one https://github.com/apple-opensource/xnu/blob/master/bsd/netinet/udp_usrreq.c#L1463?) has log statements like the KERNEL_DEBUG. However, I haven't found any kind of log messages in the system logs, that relate to UDP communication when these packets go missing. So I was wondering if there was some way to get any kind of logging generated at runtime on these systems? You note above errno logs in your reply. Is there some specific file/location where those get logged, so that I can take a look? Not every single run shows up this issue, but it does happen consistently enough that I think understanding the real reason for them being dropped would help ruling out any unexpected bugs either in the application or some other place.

Having said that, I can mark a post as Apple Recommended, which is what I’ve done for your thread. Thank you Quinn. That's good enough. I just checked that thread and the Apple Recommended answer appears before the accepted answer, so that's a good thing. Thank you for your help.

macOS 12.4 GA has been released a few days back and even 12.5 Beta version. Both these versions continue to have this bug. On the official feedback issue that was submitted, I haven't received any response. It's a bit disappointing that the Beta OS was tested, an issue was identified and feedback was logged but yet the bug made it to the GA version without receiving any response on the feedback issue. As far as I know, the feedback assistance tool is the official recommended tool for reporting these issues. Is there anything we could have done differently to try and get attention to this issue? Some other channel or issue tracker? The feedback issue has the necessary context and details of which project this affects and how widely that project gets used and the impact of this bug. So we were hoping we would get some attention on it. Furthermore, this isn't really an one off issue, there's at least one other issue which we have filed that hasn't received any response.

Finally, is there a doc/schema which explains the structure/contents of .tbd files. Not that I’m aware of. I agree there there should be and I’d appreciate you filing a bug requesting that. Please post your bug number, just for the record. I have filed FB10013233 requesting documentation for these files.

# not good. sa = util.find_library('System') sb = framework_find('System') sc = framework_find('System.framework') ga = util.find_library('OpenGL') gb = framework_find('OpenGL') gc = framework_find('OpenGL.framework') I'm not an expert in this area and new to this, but are you sure these frameworks are expected to be there in the cache at all? For example, when I extract the dyld cache and look into its contents I don't see any of these frameworks. Neither System.framework nor OpenGL.framework. In fact I don't even see Python.framework in that cache. So your "good" case - is it likely that when Python was installed that it actually installed this framework on the filesystem and your calls to util.find_library('Python') and framework_find('Python') are actually finding it on the filesystem and not from the cache?