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?

On a different thread, Quinn pointed me to the right tool to get this information. Details are available in the reply here - https://developer.apple.com/forums/thread/655588?answerId=712400022#712400022. In short, using dyld_info -dependents <library> will list the dependencies.

Oh, thanks for that context. The good news here is that we do have a way to achieve that goal, namely dyld_info. For example ... Excellent. Thank you very much. This is exactly what I was after. The only reason I used otool was because of my lack of knowledge about dynamic libraries and tools in macOS. If you find yourself in a situation where you need to look inside the dynamic linker shared cache for some reason, and that’s not covered by an existing tool, I encourage to file an enhancement request for better tooling. Make sure to describe your requirements rather than focus on one specific tool. Will certainly do going forward. 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 will do that shortly and post the id here. Slightly off-topic, but just wanted to share some feedback about the "Feedback assistance program" (the one for filing bugs) itself - I find that, that tool/process feels like "/dev/null" where you file an issue and see no updates to it at all. I don't just mean comments/responses, but even basic triaging updates like some human responding saying that it's being looked into. This observation is based on more than one issue that I have filed. The other thing with that tool is, you can't see other open issues - unlike other issue trackers where this is a common feature. So it just feels like an area where the person who has filed the issue is just talking to themselves. I'm really glad that at least the forums here are much more responsive with knowledgeable users. For example, I see that each of these file contents end with ... which at first looked odd to me Indeed. That’s a standard part of YAML. And yeah, I only know about that because I looked it up a few minutes ago (-: Thank you for that detail. I didn't even know it was a YAML format file :)