libkernel: ccleste stalls after Vulkan device ready due to redirected stderr (fixed by #4536) #4664

Activity

1. Joekrry commented on Oct 12, 2026

   

   Joekrry

   on Oct 12, 2026

   More actions

   Hi,

   I traced the exact code path.

   The four env knobs you bisect (APS5_NO_HOST_IMPORT, APS5_NO_LEASE_MIRROR, APS5_NO_SPARSE_HEAP_MIRROR, APS5_NO_PARALLEL_MIRROR_REFRESH) all gate the host-import/image-mirror machinery, and that only runs once a guest texture or buffer is bound in a draw.

   In the constructor window you point to (VulkanDevice.cpp, between "Vulkan device ready" and swapchain creation), none of the code that actually runs there, BufferPool, PipelineCache, TextureDetiler, TextureCache, GpuColorTransfer, DescriptorCache, PlaceholderImages, touches guest memory, host imports, or mirrors at all. PlaceholderImages just creates 1x1 device-local images and clears them via a GPU submit/wait. And per your own repro, the guest's main thread is still parked in sceVideoOutOpen = no draw has happened yet.

   I also checked GuestMemory::GpuMutex (correctly recursive) and RefreshPool's helper threads and no lock-ordering cycle there either.

   The bisection table doesn't line up with code that can actually run in the window described, so I can't locate the deadlock.

   Can you attach the actual run log and stack captures?
2. orishamir commented on Oct 12, 2026

   

   orishamir

   on Oct 12, 2026

   Contributor

   More actions

   This is the stall #4536 fixes. It merged at 18:31Z (21c27e6); main 9aa5fd2 above is from before it.

   The thread stacks are in #4536: the title's log reader thread is in sceKernelDebugOutText → fprintf → WriteFile, which does not return, and the thread constructing the VulkanDevice waits for the stderr lock in fprintf, called from Graphics::PrepareImportWatch (VulkanDevice.cpp:1598; on Windows that write is the [write-watch] Windows direct host imports use comparisons ... line at GuestBufferMemory.cpp:524). ccleste and RommPS move their stderr into a pipe with dup2(pipe_w, 2) and forward what they read from it to sceKernelDebugOutText, which wrote to host stderr, i.e. back into the same pipe, until the pipe was full.

   On current main cf4557e (with #4536), Windows 11, RTX 4080, WinLibs GCC 15.2.0 r7, Release, relinked with --trap-sdk-syscall-stubs, no APS5_* variables set, 60 s each:

   • ccleste (PPSA59322): Vulkan device ready, Surface capabilities ..., Swapchain created ... images=2; still running at 60 s; the frames saved every 300 presents show its title screen (logo, credits, "PS5 PORT", falling snow).
   • RommPS (PPSA76677): the same three lines; still running at 60 s; it draws its own "RomM Sync isn't running" screen (its payload loader on port 9021 refuses the connection here).

   The [write-watch] line now appears once in each title's output, forwarded by the title's reader: [debug:0] [ccleste] [write-watch] Windows direct host imports use comparisons; separate shared aliases retain guest write tracking.

   AI-assisted: yes (Claude Code Opus 5.5 xhigh)
3. AlxcBTW

   added a commit that references this issue on Oct 12, 2026

   Mark #4664 as the stall #4536 fixed; ccleste Menus, RommPS Presents o…

   ...

   b9be7fd
4. Roojool

   changed the title [-]libSceAgcDriver: VulkanDevice constructor deadlocks in guest-memory mirror/import setup after 'Vulkan device ready' (ccleste PPSA59322, deterministic)[/-] [+]libkernel: ccleste stalls after Vulkan device ready due to redirected stderr (fixed by #4536)[/+] on Oct 12, 2026
5. Roojool commented on Oct 12, 2026

   

   Roojool

   on Oct 12, 2026

   ContributorAuthor

   More actions

   Confirmed locally on Windows 11 / Radeon 780M. The original mirror/import lock-cycle diagnosis was incorrect; I withdraw it. The single-knob/all-knob outcomes did not establish that mechanism, and the original raw stack scans were not symbolic backtraces. Sorry for the misleading attribution.

   I reused G09's runtime built from bde332a59ce98ce8aa776b26a4ed04e53417946d, including its diagnostic AGC binary, and ran ccleste (PPSA59322) with no APS5_* variables:

   • Before fix(libkernel): keep sceKernelDebugOutText off a redirected guest stderr #4536: still alive at 45 seconds; last stdout line Vulkan device ready; no surface-capability or swapchain line. Stopped by the test harness.
   • Rebuilt only libkernel after applying the two already-merged fix(libkernel): keep sceKernelDebugOutText off a redirected guest stderr #4536 commits (2585eeb7e, fc0d46ba0, original authors preserved), leaving AGC and every other runtime library identical: surface capabilities and swapchain created; continued logging guest GPU submissions through the 45-second observation window. Stopped by the test harness.

   Actual output excerpts:

   [src\VulkanDevice.cpp:1588 VulkanDevice] Vulkan device ready device=0000000009f94180 queue=0000000009f9f0d0 family=0
   [src\VulkanDevice.cpp:1645 VulkanDevice] Surface capabilities drawable=1152x648 min=1152x648 max=1152x648 minImages=2 maxImages=16 usage=0x9f
   [src\VulkanDevice.cpp:1689 VulkanDevice] Swapchain created swapchain=000000000a1d91f0 extent=1152x648 images=2
   [debug:0] [ccleste] [write-watch] Windows direct host imports use comparisons; separate shared aliases retain guest write tracking
   [debug:0] [ccleste] radv/ps5 submissions: window count=355 kwords=340 claim_ms=0.6 copy_ms=3.1 flush_ms=0.2 agc_ms=17.3 suspend_ms=5.5
   [debug:0] [ccleste] radv/ps5 submissions: window count=599 kwords=581 claim_ms=1.4 copy_ms=6.7 flush_ms=0.4 agc_ms=33.3 suspend_ms=3.3
   [debug:0] [ccleste] radv/ps5 submissions: window count=600 kwords=582 claim_ms=1.2 copy_ms=5.8 flush_ms=0.3 agc_ms=28.7 suspend_ms=3.0
   [debug:0] [ccleste] radv/ps5 submissions: window count=599 kwords=581 claim_ms=1.4 copy_ms=7.0 flush_ms=0.4 agc_ms=34.1 suspend_ms=3.3
   

   This is a before/after check of the existing merged fix on the saved runtime, not a full latest-main title run. I did not rerun RommPS. The initial attempt to substitute a much newer kernel into the older runtime failed at DLL loading and was excluded from the comparison.

   The evidence agrees with @orishamir's explanation: the title's stderr-capture reader fed sceKernelDebugOutText back into its own pipe. #4536 breaks that loop by preserving host stderr. Thanks @Joekrry for questioning the constructor-path claim and @orishamir for the exact diagnosis and verification. Closing as already fixed by #4536; no separate G09 fix PR.

   AI-assisted: yes.

   👍React with 👍2Reacted by Ori Shamir and Joe kerry
6. Roojool

   closed this as completedon Oct 12, 2026