Bug description: The Coherrent GT debugger is crashing the sim. Started two days ago. I just installed the latest SDK so I reverted back. Then I reverted back to SU3 from SU4. Nothing fixed my issue. I wonder if I have too many pages under a single app. What is going on? I found an old 2020 post and the guy mentioned that the debugger also will stop working. This also happens. My solution rather than restarting the PC is to run the sim then open the debugger then close the sim and debugger. Then the next time you run the sim it will come back to life.
I can send my project as I was already planning to for the Pneumatic system report.
This has always been a problem, that seems very random and unpredictable. It seems much more likely when the framerate is lower or stuttering for some reason IME. Sometimes it helps to pause the sim (ESC key), connect the debugger to your instrument (do not add any breakpoints yet, as they fairly reliably crash on resuming the sim like this), and then resume and start working as normal. Even that is not foolproof and will sometimes crash during resume. Rebooting the PC can sometimes help if it’s happening consistently.
I will send over the report I have to your inbox. But we already basically solved the issue.
Summary
From my testing, the CTD only occurs when the Coherent GT debugger is attached while I’m actively working on my custom EFB tablet (pneumatics page). When I run the same aircraft and tablet without the debugger, the sim is stable and I can use the tablet as long as I want with no crash. The RAI report shows the crash happening inside the sim’s own engine (KittyHawk / Coherent UI), not inside my WASM module, and all four Coherent/Renoir caches (ScratchLayer, ScratchTexture, Texture, DepthStencilTexture) are pegged at about 4096 MiB. That strongly suggests a Coherent/Renoir memory issue when the debugger is attached, rather than a direct bug in my JS/TS or WASM logic.
My tablet app is fairly heavy: it uses a couple of large high-resolution images and now has quite a few pages, so it’s a good stress test for the UI system. However, this heavy setup only becomes a problem when combined with the Coherent GT debugger. For normal end users, who will never run the debugger, I do not see this CTD at all — they can use the full tablet with all pages and large images without hitting this crash. My main goal in sending this report is to help you track down the Coherent/debugger memory behavior so developers can safely use the debugger with complex EFB-style UIs.
Detailed technical note
In the attached RAI Report.toml, under [CoherentGT_CachesMiB], all four Renoir caches (RenoirScratchLayer, RenoirScratchTexture, RenoirTexture, RenoirDepthStencilTexture) are reported as 4095.999999 MiB. That value is effectively 4 GiB per cache, which is a very strong indicator that these pools are hitting an internal 4 GiB ceiling rather than growing freely. At the same time, the engine section reports total AllocatedMem of roughly 9.2 GB, and the renderer section shows a VideoMemoryBudget of about 15.9 GB, so the system as a whole still has headroom when the crash occurs. This combination — Coherent Renoir caches saturated at ~4 GiB each, crash in KittyHawkx64_PCSUB, and no third-party WASM in the callstack — strongly points to an internal Coherent/Renoir allocation or leak pattern when the GT debugger is attached, rather than global system memory exhaustion.
