“eskimo”

Thank you Eskimo for your answer. --> there is no crash report generated (only a killed message) --> the Console does not report anything. However, when launching into the debuggr lldb, some info appear in the Console : Issued commands : $ gcc simplest_ever_c_program.c -o simplest_ever_c_program $ lldb simplest_ever_c_program (lldb) target create simplest_ever_c_program Current executable set to '<...>/simplest_ever_c_program' (x86_64). (lldb) run Process 83292 launched: '<...>/simplest_ever_c_program' (x86_64) Process 83292 exited with status = 9 (0x00000009) Terminated due to signal 9 (lldb) run error: process exited with status -1 (no such process) (note that first launch in lldb reports a crash with signal 9, while next launch fail to start with no such process) At first launch within lldb, the Console finally reports some informations. Console reports : par défaut 12:56:32.644706+0200 kernel Allowing set_exception_ports from [debugserver] on [simplest_ever_c_program] for entitl

[quote='904457022, fortens-dev, /thread/844906?answerId=904457022#904457022, /profile/fortens-dev'] The reason I was considering two executables was purely to minimize the amount of application code that ever runs as root. [/quote] OK. That’s a worthy goal, but I think it engenders too much risk in this case. One alternative would be to move this code into a shared library that the main tool loads after dropping its privileges. That makes it easy to audit that the main tool can’t do any XPC before that transition. [quote='904457022, fortens-dev, /thread/844906?answerId=904457022#904457022, /profile/fortens-dev'] Is that single-process pattern supported for an SMAppService LaunchDaemon with a declared MachServices entry? [/quote] It’s hard to guarantee that. Your plan is reasonable enough — specifically, Mach IPC is capability based, so it won’t be affected by changes to your BSD privileges — but it’s still weird, and weird stuff is more likely to break that standard stuff. However, I think it represents a rea

[quote='845112021, familyspace-dev, /thread/845112, /profile/familyspace-dev'] I then exported the IPA locally using Xcode's App Store Connect distribution workflow [/quote] If you export from the organiser and then upload that .ipa using altool (or Transporter), do you have the same problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hmmm, that’s weird. On Apple silicon there’s a standard explanation for problems like this. Apple silicon programs must always be code signed. To support this sort of workflow the linker defaults to signing programs, something you can explicitly opt in to and out of via command-line options. However, you’re on Intel and Intel Macs supports code that’s completely unsigned. When your program crashes it should generate a crash report. Please post an example of that. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks, eskimo. Your suggestion worked. I packaged the exact same signed app into a DMG, without rebuilding, re-signing, or changing any bundled resources. Apple accepted the submission with no issues. The same app had previously failed notarization when submitted as a ZIP. The app includes a 5.35 GB model file that required ZIP64 in the original archive, so this result is consistent with the issue you flagged. This resolves our notarization blocker. Appreciate your help!

AFAIK there’s been no change in this space. Certainly, none of the bugs mentioned on this thread (FB7380536, r. 56352596, FB9835553, FB24698778) are marked as resolved. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844947021, Pavel, /thread/844947, /profile/Pavel'] the Transparent Proxy API does not have a concept of an asynchronous/delayed verdict for flow authorization. [/quote] Correct. [quote='844947021, Pavel, /thread/844947, /profile/Pavel'] This creates a significant bottleneck when establishing new network flows. [/quote] Indeed. Something has to give here. You could reasonably file an enhancement request for Apple to support multi-threading in handle-new-flow calls, but it’s hard to imagine that happening in a useful timeframe. The obvious short-term fix — changing your architecture to run these queries in fast, synchronous manner — will likely yield the results you need before any ER could land. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

macOS really prefers folks to combine fork and exec*. Doing a fork without an exec* is an ongoing source of weird issues. Doing an exec* without a fork is less problematic, but still concerning. I’m not sure I understand why you need two executables here. What’s the problem with running the setgroup and so on in the startup sequence of the main executable? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844975021, PR607, /thread/844975, /profile/PR607'] The inference model […requires] ZIP64 sizes. [/quote] I think that’s going to be problematic. Apple tooling has had various problems with ZIP64 (FB11516428, r. 51442499) and AFAICT the root cause remains unfixed )-: For the sake of testing, what happens if you create a disk image (.dmg) of your full app and try to notarise that? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for the crash report. And, yeah, from that I can confirm that this is most definitely a bug in altool. Please file a bug about this, including the crash report and the verbose log output. Once you’re done, post the bug number here and I’ll add my own internal analysis of it. I don’t see any way around this other than to remove the @ from your app’s name )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='904202022, MagicYassin, /thread/844296?answerId=904202022#904202022, /profile/MagicYassin'] and it's FB24627880. [/quote] You mean FB24627080, right? Because FB24627880 is a bug about Final Cut! ps I avoid minor niggles like this by always copy’n’pasting bug numbers (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='904229022, vocaro, /thread/843599?answerId=904229022#904229022, /profile/vocaro'] the trap no longer reproduces. [/quote] Well, that’s welcome, but it’s not incompatible with my earlier comments. The nature of such problems is that they come and go as the Launch Services database thrashes around. If it comes back, try reproducing the issue as the user would. I typically use a VM for this sort of testing, because it lets me reset the machine to a known good state between tests. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='904156022, Qinhan_Li, /thread/844516?answerId=904156022#904156022, /profile/Qinhan_Li'] it cannot receive app notifications [/quote] OK, that’s a valid use case. For Wi-Fi, an iOS device with WWAN will shut down the Wi-Fi interface to save power, relying on WWAN for push notifications. OTOH, if the device doesn’t have WWAN, it’ll attempt to stay associated with Wi-Fi for these admins tasks. I would expect this to work the same way on Ethernet, but I must admit that I’ve never tested this. Is this problem tied to your accessory? Or do you see the same issue if you use a generic off-the-shelf USB Ethernet adaptor? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='904164022, MandoMike45, /thread/835400?answerId=904164022#904164022, /profile/MandoMike45'] the _ = CKRecord.self … workaround described here is not reliable [/quote] That’s not the technique I suggested. The compiler may well decide that fetching the type’s metadata has no effect. What I suggested was calling print(…). I suggested that because it generates I/O, and the compiler is not allowed to optimise that I/O away. If you find that the print(…) workaround is failing, then something else has gone wrong. It’s possible that there’s a compiler bug but I think that’s unlikely in this case. What’s more likely is that the code where you put the print(…) call got optimised away. Regardless, this warrants further investigation at your end. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So CL should give you some execution time as it delivers the update. You can also use ProcessInfo to extend that a little (see UIApplication Background Task Notes). Have you tried running your upload in a standard session during that time? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com