Mercury. Mission 3: (Campaigns\Historical_MercuryAtlas6\Missions/friendship7).Crash !!! :sos:

[exotic wren]

Mercury. Mission 3: (Campaigns\Historical_MercuryAtlas6\Missions/friendship7).
Crash !!! 🆘 😭 😭😭 At mark 002:17:29

Current Mission Message: Vetin Anton: Это Дружба Семь. Слышу хорошо, офицер связи Индиана. Это Дружба Семь. Я сейчас на прямом ручном управлении (рысканье). У меня 92 процента топлива, на... на ручном, авто топливо на 64. Приём.
Current Mission Message:
002:17:25: CC: Принято, вас понял - управляете вручную. Приём.
Current Mission Message: CC: Принято, вас понял - управляете вручную. Приём.
Current Mission Message:
AC Selector: 1
002:17:29: Vetin Anton: Верно, перешел в режим ручного управления. Есть сигнальная лампа количества топлива по авто-каналу. Пока всё хорошо. Капсула под контролем и использую ручное. Приём.
Current Mission Message: Vetin Anton: Верно, перешел в режим ручного управления. Есть сигнальная лампа количества топлива по авто-каналу. Пока всё хорошо. Капсула под контролем и использую ручное. Приём.
Crash!!!

Here files from C:\Users\Vetin\AppData\Local\Temp\Wilhelmsen Studios\ReEntry\Crashes\Crash_2025-11-10_182552891

[urban tree]

@exotic wren could you try one of the test-branches Petri made?

[exotic wren]

Yes, I can try.

Which test-branch should I use for reproducing the Mercury-Atlas 6 crash?

[urban tree]

They're named "crashtest", I'm thinking try them iteratively until you find one that doesn't crash

[exotic wren]

I suspect the crash is caused by a memory leak or invalid deallocation in Unity’s job/allocator system, triggered during the long-running Mercury-Atlas 6 mission logic.

In the logs, after an extended session, there are continuous warnings:
• Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak

Shortly before the crash, these escalate to:
• Invalid memory pointer was detected in ThreadsafeLinearAllocator::Deallocate!

followed by Crash!!! with the stack trace inside UnityPlayer.dll.

This pattern suggests that one of the systems used heavily in MA-6 (mission messages, checklists, UI, audio, or related jobs) is not releasing temporary allocations correctly, eventually corrupting the ThreadsafeLinearAllocator state and causing a native crash, independent of my hardware or settings.

[exotic wren]

Got it, thanks. I’ll switch to the crashtest branches in Steam and try them one by one.
For each branch I’ll run the historical Mercury-Atlas 6 mission the same way (manual control etc.).
If it crashes, I’ll upload the corresponding Player.log and crash dump with the branch name.
If one of the crashtest builds completes MA-6 without crashing, I’ll report that as well.

[inland sapphire]

Gave +1 flight-hours to @urban tree (current: #1 - 567)

[exotic wren]

i’m setting up “crashtest - Crashtests” branch, and come back when finish.

[orchid cliff]

Just to make sure since I have evolved from this: The branch to use is the Alpha-Floor branch, not the Crashtest

[exotic wren]

Greetings! I saw the new patch today. Could you tell me if the issue I reported has been fixed, or should I still enable the “Alpha-Floor branch”?

[orchid cliff]

You can play on the normal None branch (meaning release branch) now, since I got quite a few other data points here and over e-mail that the fix corrects the crash (at least for them). Please let me know how it goes for you. The Internal: JobTempAlloc is an internal Unity thing and was caused by Unity 6.1 on some hardware (probably yours as well since you are seeing this).

[exotic wren]

Thank you so much!

[inland sapphire]

Gave +1 flight-hours to @orchid cliff (current: #3 - 397)

[orchid cliff]

Likewise, let's get this issue solved 😄

[exotic wren]

Greetings!

Here my test-report.

I completed this mission all the way through - there was no crash. But, even with all procedures followed correctly and precisely, the landing point ended up much earlier than planned.

This may have been caused by one of two factors:

I had the “real Mercury orbits” option enabled.

After the retro rockets fired in automatic mode, I did what I usually do: I set the spacecraft to a positive pitch of +35 degrees and started spinning, because the ASCS automation did not do this by itself after switching ATTITUDE SELECT to the RE-ENT position.

[orchid cliff]

Thanks for the report, and glad to hear the crashing has stopped for you. The Orbital Decay can have an influence indeed. I will have a go at this mission agian soon. I have a recording here that can be used to compare: https://www.youtube.com/watch?v=QOjRCDvwZug