Open warpdesign opened 1 year ago
Thanks for the bug report, unfortunately none of the main maintainers are macOS users so we have relied on drive by contributions to fix macOS issues so far. Can you confirm where you have put the data extracted from the original game discs as per https://github.com/TheAssemblyArmada/Vanilla-Conquer/wiki/Installing-VanillaTD or https://github.com/TheAssemblyArmada/Vanilla-Conquer/wiki/Installing-VanillaRA as this could be a data issue.
Yes, as mentioned I copied vanillara.app next to redalert.mix
& main.mix
(I am testing the RedAlert demo).
I'll try Red Alert freeware release.
I found out that opening the macOS vanillara.app
directory & copying the datas directly into vanillara.app/Contents/macOS/
works, but this should not be needed: you are not supposed to modify .app directories.
Also, how about printing an error message instead of crashing when the data cannot be opened?
Very strange, might it be related to the name of the user directory? Any special characters inside?
I have tested the application on a MacBook Pro 2021 and a MacMini 2020 successfully. Both ARM64. When I find some time, I will also test a MacBook Pro 2019, x64.
No special character in the user directory.
I was not able to reproduce your issue on my machines, even not when I force the universal build into the x64 mode. Interesting might be that your log mentions a "haswell variant" in the failing thread. So it might be only happening on Macs with Haswell CPUs. Google finds some similar bug reports of other software mentioning such a stack trace.
So I will do some further investigations what this issue is about. Maybe I will be able to fix it blindly, without being able to debug it.
Let me know if/how I can help you.
I checked the source code but I am not able to find any flaw so far. Another test on an Intel-based MacBook Pro 2019 was also successful. Could you please double-check that you have placed the game files in the correct directories "/Users/username/Library/Application Support/Vanilla-Conquer/vanillara" and "/Users/username/Library/Application Support/Vanilla-Conquer/vanillatd"?
Is there still an issue or can this bug report be closed?
I presume that there were a misunderstanding, not a bug. For macOS the game data files must reside in the Application Support folder of the current user and not beside the app bundles.
When starting
vanillara.app
orvanillatd.app
, the screens goes black, then the app crashes with this error:Crash Log
------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: vanillara [2460] Path: /Volumes/VOLUME/*/vanillara.app/Contents/MacOS/vanillara Identifier: com.vanilla-conquer.vanillara Version: 1.0 (1.0) Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-03-11 12:38:49.8906 +0100 OS Version: macOS 13.2.1 (22D68) Report Version: 12 Anonymous UUID: DE31D4ED-79A0-C427-28F9-35FC6FE0332C Time Awake Since Boot: 1200 seconds System Integrity Protection: disabled Notes: dyld_process_snapshot_create_for_process failed with 5 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [2460] VM Region Info: 0 is not in any region. Bytes before following region: 4302372864 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100710000-1008b0000 [ 1664K] r-x/r-x SM=COW ...cOS/vanillara Error Formulating Crash Report: dyld_process_snapshot_create_for_process failed with 5 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x7ff80f83f110 _platform_memmove$VARIANT$Haswell + 240 1 vanillara 0x1007b4ce4 Init_Game(int, char**) + 2932 2 vanillara 0x100768e13 Main_Game(int, char**) + 19 3 vanillara 0x10081145e main + 1438 4 dyld 0x7ff80f4e4310 start + 2432 Thread 1: 0 libsystem_pthread.dylib 0x7ff80f812c58 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x7ff80f812c58 start_wqthread + 0 Thread 3:: caulk.messenger.shared:17 0 libsystem_kernel.dylib 0x7ff80f7d853e semaphore_wait_trap + 10 1 caulk 0x7ff818f8a8f8 caulk::mach::semaphore::wait_or_error() + 16 2 caulk 0x7ff818f70664 caulk::concurrent::details::worker_thread::run() + 36 3 caulk 0x7ff818f70328 void* caulk::thread_proxyConfig