Cult of the Lamb (PPSA06465) on Windows: intermittent fault in Loading.PreloadManager during start-up (about half of 40 s runs) #5490

Activity

1. MarcZX10 commented on Oct 13, 2026

   

   MarcZX10

   on Oct 13, 2026

   Contributor

   More actions

   Thanks for the detailed reproduction. One check may separate malformed input from a synchronization race: does /app0/Media/Resources/unity default resources exist in this dump, and on a failing run does its sceKernelOpen succeed? If you can capture a lightweight trace for just that path (open result, each read offset/byte count/result, and the last successful read before the fault), it would show whether the deserializer receives a short/error read or complete data. A missing asset was one possible lead in the older Unity Loading.PreloadManager report (#3805), though it was never established there either. The 4/8 vs 5/8 rates don’t clearly show that #4973 changes this fault, so I wouldn’t infer either way from those samples.
2. p3n1cillin commented on Oct 13, 2026

   

   p3n1cillin

   on Oct 13, 2026

   Author

   More actions

   Thanks. I checked both questions with a local-only logging build: main c7601b797, plus logging in sceKernelOpen/Close/Read/Lseek/Pread/Fstat for that one path's descriptor.

   • The file exists. Media/Resources/unity default resources is 3,740,432 bytes in the dump, and sceKernelOpen succeeds every time (fd 4 or 6).
   • The reads are complete and identical in faulting and non-faulting runs. Over 6 runs of 40 s (5 faulted), the sequence was always:

     open fd=4 flags=0x0                      (tid A)
     pread fd=4 at=0      n=65536 -> 65536    (tid A)
     pread fd=4 at=327680 n=65536 -> 65536    (tid A)
     pread fd=4 at=393216 n=65536 -> 65536    (tid A)
     pread fd=4 at=327680 n=65536 -> 65536    (tid A)
     close fd=4 -> 0                          (tid B = Loading.PreloadManager)
     

     There were no read, lseek or fstat calls on it. In faulting runs the fault follows that close on the same Loading.PreloadManager thread, for example app.exe+0x453b2e writing to 0x0.

   So the deserializer gets complete data for this file, and it isn't a short or error read here. The fault comes after the file has been consumed and closed.

   One run differed. The file was opened a second time later and got fd 0; then pread at=0 n=65536 and pread at=1075060 n=113428 both returned in full. That run ended with FATAL: UCRT invalid parameter on another thread, at libc.prx+0xb4b8 (host libc) called from libc.prx+0xaf5da. I'm not sure that is the same problem, but a file getting descriptor 0 may be worth a look on its own.
3. MarcZX10 commented on Oct 13, 2026

   

   MarcZX10

   on Oct 13, 2026

   Contributor

   More actions

   Thanks, this rules out a missing or short unity default resources read on both faulting and successful runs. The close immediately before the null write is useful timing, but the complete, identical reads mean I don't see a file-I/O change justified by this trace alone.

   The fd-0 run may be a separate clue: the guest descriptor checks I found treat only negative values as invalid, so descriptor 0 is valid here. If that UCRT invalid-parameter report recurs, a stack or the invalid-parameter arguments would help identify which CRT call rejected them; I wouldn't tie it to the intermittent null write yet.
4. EagleBearerYS commented on Oct 14, 2026

   

   EagleBearerYS

   on Oct 14, 2026

   Contributor

   More actions

   If you have time for another series: two open PRs change libkernel behaviour that could fit your "synchronisation primitive returning early" candidate. I haven't run Cult of the Lamb, so this is a guess.

   • fix(libkernel): hand signalled semaphore tokens to queued waiters #5412: sceKernelSignalSema hands its tokens to the waiters already queued. On main, a sceKernelPollSema or sceKernelWaitSema that runs first can take them, so a queued waiter can time out or keep waiting. fix(libkernel): release event flag waiters when the pattern is set #4899 does the same for event flags.
   • fix(libkernel): block a signal while its handler runs and honour SA_RESETHAND #5312: a signal handler runs with its own signal blocked, as on FreeBSD, and setjmp/longjmp save and restore the signal mask. That would matter if IL2CPP's collector stops threads with signals.

   If the fault rate changes with either of them merged into main, that would narrow it down.
5. p3n1cillin commented on Oct 14, 2026

   

   p3n1cillin

   on Oct 14, 2026

   Author

   More actions

   Thanks @EagleBearerYS, I ran that series. main a453108cf was compared with each PR merged onto it, in alternating 40 s runs (Windows 11, same relinked app.exe, only the libraries swapped):

   libraries	first series (6)	second series (10)	total
   main	4	4	8/16
   + #5412 (semaphore hand-off)	2	—	2/6
   + #4899 (event flag hand-off)	1	5	6/16
   + #5312 (signal mask in handlers, setjmp)	3	—	3/6

   #4899's low first count didn't hold up over 10 more rounds, so none of the three clearly changes the rate. The faults keep the same mix of shapes with every set: 0xc0000005 on Loading.PreloadManager, abort(), and UCRT invalid parameter. #5412 and #5312 only had 6 runs each, so a smaller effect from them isn't ruled out.

   AI-assisted: yes (Claude Code)
6. EagleBearerYS commented on Oct 14, 2026

   

   EagleBearerYS

   on Oct 14, 2026

   Contributor

   More actions

   Thanks for running the series. I read it the same way: none of the three clearly changes the fault rate, and #4899's early dip didn't hold over the longer series. With 6 runs each, a small effect from #5412 or #5312 isn't ruled out, but nothing here points to either of them.