Repository navigation
Support createdump functionality in the app sandbox #119945
Description
The 'createdump' tool doesn't currently work in the app sandbox (i.e. when publishing to the App Mac Store).
Ref: dotnet/macios#16189
Making it work as a standalone executable has numerous challenges:
createdumphas to be signed with a bundle identifier. It doesn't seem like the same bundle identifier as the main app can be used, although I wasn't able to confirm this (in any case it sounds like a bad idea to re-use the bundle identifier).createdumprequires a few custom entitlements: https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/createdump-entitlements.plistcreatedumpwould also need the sandbox entitlement to publish to the App Store (com.apple.security.app-sandbox).- I'm not entirely sure whether a custom provisioning profile is required. If so,
createdumpwould have to be put inside an app-like directory structure: https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement. This is inconvenient, because CoreCLR expectscreatedumpnext to one of its dylibs. Maybe this can be worked around with a symlink? - It seems that since a bundle identifier is required, an Info.plist must be embedded inside the executable, which is done when the executable is linked (by passing
-sectcreate __TEXT __info_plist path/to/Info.plistto ld)... but we get the executable already linked from the runtime pack.
Also interesting: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app
An alternative approach seems to be to embed the createdump functionality as a static library, and then potentially fork before generating the dump. This is apparently what .NET does for single-file executables.
Ref: #84864
Ref: #89203
Ref: https://discord.com/channels/732297728826277939/732297808148824115/1149344656480550912
In any case, we don't even know if there's community interest in supporting createdump functionality in the app sandbox, so if you're interested, please upvote this issue. If we get enough interest, we'll look into it, otherwise we'll eventually close this issue.
Activity
rolfbjarne commentedon Sep 19, 2025
Fixing dotnet/macios#23848 would probably make this trivial to fix.
steveisok commentedon Sep 19, 2025
Can you transfer this over to runtime? We're going to look at this generally as part of consolidation.
rolfbjarne commentedon Sep 22, 2025
@steveisok note that this is only applicable to macOS and Mac Catalyst apps, iOS and tvOS apps aren't allowed to execute other executables.
dotnet-policy-service commentedon Sep 22, 2025
Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.
steveisok commentedon Sep 22, 2025
@dotnet/dotnet-diag as I mentioned earlier, we should factor this in when planning diagnostic work for runtime consolidation in 11. It's very likely once we decide on the options, we come back to this issue and fold it in.
Youssef1313 commentedon Nov 3, 2025
https://github.com/Youssef1313/DumpTestMacOS/ This repo shows also some issues with creating dumps on macOS. For now only workaround we have in the testing space is disabling apphost, and running directly under dotnet instead. The GitHub Actions in that repo sets up different combinations.
I hope a fix for this issue would also fix the issues we see in the testing space.
Note that xunit.v3 doesn't set allow disabling apphosts as of today. So the workaround isn't available for all xunit.v3 users. xunit/xunit#3432
rolfbjarne commentedon Jul 28, 2026
While not a direct fix for this issue, #131410 would serve the same purpose (allowing crash reports for sandboxed apps), but using the inproc crash reporter.
lateralusX commentedon Jul 28, 2026
@rolfbjarne, given that we land #131410, do you believe it's good enough to close out this issue?
rolfbjarne commentedon Jul 28, 2026
Yes, I think we can close this issue then. I can always reopen if I change my mind.
Enable in-proc crash reporting on MacOS + Linux (#131410)