This crash is caused by a bug in VirtualBox. A possible workaround is to disable Audio in the settings for that virtual machine.

On 11.0.1 Beta (20B5022a) bryan@nvbigsur mapfail % cc -m64  -g -Wall -Werror -o mapfail mapfail.c bryan@nvbigsur mapfail % codesign -vvvv mapfail mapfail: code object is not signed at all In architecture: x86_64 bryan@nvbigsur mapfail % ./mapfail 10000000 10000 maping from 0x10000000 to 0x10010000 is OK Unable to reserve 0x10000000 for the test1 heap,  using 0x10ad37000 instead test1 heap mapped from 0x10ad37000 to 0x10ad48000 bryan@nvbigsur mapfail % 

I think the only way to recover this is to reinstall macOS and then restore your data from your most recent backup. You are not alone in having done this - I made a similar mistake 30+ years ago on a Solaris machine, but fortunately had a full (and recent) backup to recover with. Consider it as a 'rite of passage' to being a Unix system admin and don't do it again :)

By default CCC will only do a clone of the Big Sur data volume. I suspect that you have not made a bootable backup, i.e. also including the system volume. The CCC web-site has details on how to make a bootable backup with CCC running on Big Sur.

I am pretty sure the limiting factor here is not the RAM allocated to the copy/move process but instead the speed of your devices. What is the transfer rate of your source device? What is the transfer rate of the target? Are you using USB? Are these SSD devices? Is it a network connecton? All of these have for more impact than the amount of memry allocated to the process.

@mikeyh Thank you so much for this. I have just tried your patched code and it is working in my build process. I'll refrain from marking your solution as accepted for now, just in case there are more comments/improvements from others, but it seems to be working fine.

I have a suspicion that this problem is related to the libresolv security patches applied in https://support.apple.com/en-us/HT213257 and https://support.apple.com/en-us/HT213256.

I have a suspicion that this problem is related to the libresolv security patches applied in https://support.apple.com/en-us/HT213257 and https://support.apple.com/en-us/HT213256 to macOS. Presumably this same libresolv security fix was also applied to iOS.

I ran into a similar problem a few months back. The solution was to upgrade SMJobBlessUtil.py to python3. The issue was covered in https://developer.apple.com/forums/thread/699310 The conversion seems to work but I have only run it with my own use cases and not done any rigorous testing.

If you are using an Apple Silicon Mac, have you tried running the script under Rosetta2?

I run the script under rosetta on an M1 with python3 by using: arch -x86_64 scripts/SMJobBlessUtil-python3.py check path_to_bundle It seems to work

Not a commandline solution but whatroute (https://whatroute.net) will perform tcp traceroute.

Instead of looking to call Swift from C++ you should probably look at it the other way round. Use Swift as the main language for your development - it integrates beautifully with Interface Builder and is ideally suited for building a gui. You can then make calls to C/C++/Obj-C using the Swift bridging interfaces. Admittedly there is a bit to learn but I think you'll find Swift to be quite easy to become familiar with. I have found C/C++ to be very useful in Swift applications for dealing with Posix/System interfaces, then passing results back to Swift either as arguments or via closure/callbacks.

Submitted FB12051702 with a sample project demonstrating the failure.

Fixed with Xcode 14.3 beta 3