Repository navigation
Sifu (PPSA03001): RenderThread faults popping a free list whose head reads 0xFFFFFFFFFFFFFFFF #3209
Description
AI-assisted (Claude Code), reviewed by the contributor.
Title: Sifu (PPSA03001, from the owner's own dump), Windows. Relinked from the reconstructed ELFs (eboot plus 31 prx, 37 modules); the import audit reports 0 absent imports.
Observed: the title runs for a while and then RenderThread 1 faults with an access violation, reproducibly (two runs, same pool):
FATAL: unhandled exception 0xc0000005 on thread 'RenderThread 1'
rip app.exe+0x1bc2586 read of 0xffffffffffffffff
rax 00000020193b0000 rsi 00000020193b0220 rcx ffffffffffffffff
[rax] ffffffffffffffff ffffffffffffffff ... (all 0xff)
[rsi] ffffffffffffffff fffffffffffffffe ...
The second run faulted a few instructions away (app.exe+0x1bc2700) with rcx 00000020193b0060, so it is the same pool at 0x20193b0000.
What the code does (disassembly of the relinked app.exe around 0x141bc2586): it pops an entry from a free list. It loads the head pointer from [rsi], tests it for zero (empty list), decrements a counter and then reads [head]. The head here is 0xffffffffffffffff and the memory around it is all 0xff, so the zero test does not catch it and the next read faults.
Not established: who writes 0xFF into that region. It is either the title (a poison or "empty" fill that a later step is supposed to replace) or memory that our direct/flexible mapping hands out without the content the title expects. I did not find a 0xFF fill in libkernel/DirectMemory. I also did not identify which mapping call created 0x20193b0000: a gdb trace of the kernel memory calls stopped early under the debugger and did not reach that region.
If someone knows how this title's allocator initialises these pages, or has a quick way to log writes into a guest range, that would settle it. Other output of the run: many unsupported registered shader type 8 lines (shaders not prepared at registration), no other error.
Activity
ArjenS-LA commentedon Oct 11, 2026
There are two existing Windows diagnostics that may help trace this without the gdb session:
APS5_TRACE_MEMORYlogs mapping, protection and release operations.APS5_WATCH_ADDRwatches eight bytes at an absolute address and reports trapped writes with the writer?s location. The address above targets[rsi], the free-list head in your first capture; adjust it if the allocation moves between runs.Sources at main
961b25fe: memory tracing, write watcher.The watcher polls until the page is committed, so initialization can happen before it arms. It also temporarily makes the page writable while single-stepping. Consequently, no reported write would not rule out an earlier or concurrent write.
Could you include the exact AnyPS5 commit/extra patches, the mapping entry covering this address, and any
[watch]output before the crash? That would help distinguish incorrect initial contents from a later overwrite. I checked these diagnostic paths in source; I haven?t reproduced Sifu locally.xXPBSXx commentedon Oct 11, 2026
Update: this is fixed by the
sceKernelAvailableDirectMemorySizechange from #3143 (branchfix/libkernel-available-direct-memory-largest-block), no other change involved.Check: same relinked Sifu, same machine, same libraries, only that one file differs.
APS5_TRACE_MEMORY=1) with no fault; the 70 s run was still going when I stopped it, compiling shaders and creating textures, no error line.RenderThread 1faults again at the same place,app.exe+0x1bc2586,read of 0xffffffffffffffff.My reading, not verified: the title sizes or places its pool from what
sceKernelAvailableDirectMemorySizereports, and the first-gap answer led to the pool being used before it was filled. I have not looked at why the memory reads as 0xFF in the failing case. The issue can be closed together with #3143 once that change is merged.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 11, 2026
Thanks to @AchrafReyani for carrying the
sceKernelAvailableDirectMemorySizechange (#3292, merged); that is the change that fixed this Sifu fault in my bisect (see above), so this issue should be fixed onmain. I have not rerun Sifu on a puremainbuild since the merge, only on my test branch.AI-assisted (Claude Code).
oneandonlydean commentedon Oct 11, 2026
Closing: fixed by #3292, per the bisect above. Reopen if PPSA03001 still faults there on plain main.
xXPBSXx commentedon Oct 11, 2026
This issue is closed, but I could not confirm the fix on current
main; reopen if you agree. Sifu (PPSA03001), relinked from thePPSA03001_elf_v2reconstruction with the relinker ofmainf990506 (37 modules; the import audit shows 1 absent import,sceSaveDataDialogUpdateStatus), Windows 10, 90 s runs with the libraries ofmainf990506, ca4ab0d and a11c8f7 (the change from #3292 is in all of them): the run does not reach the render thread, it stops in Unreal's start-up withPS5 Out of Memory ... UsedPhysical 9278849024, AvailablePhysical 4902027264andRan out of memory allocating 5565054976 bytes with alignment 65536, followed by a fault in the title's ownlibc.prx. Demon Slayer (PPSA03490) stops on the same allocation (see #3073). I do not know whether this differs from the setup in which theRenderThread 1fault was fixed (a different reconstruction or data set would explain it); the free-list fault could not be re-tested because the title stops earlier.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Bisect result for the Sifu change since the earlier fix, with evidence. Setup: Sifu (PPSA03001) relinked once (the same
app.exefor every step, so only the libraries differ), Windows 10,mainlibraries built per commit,git bisectover first-parent merges, each step a 60 to 75 s run under the game lock.mainjust before (74a0ba3) and just after (b6f649d) the fix(libkernel): report the largest free direct memory block from sceKernelAvailableDirectMemorySize #3292 merge: about 1,500 log lines of shader and texture activity, no abort, no memory error (90 s runs).fix(libScePlayGo): accept chunk ids when the dump has no chunk definitions, merge 98da5a9). Adjacent first-parent commits: 6a8f0eb runs clean in 3 of 3 runs (855 to 1,114 log lines, no fatal); 98da5a9 aborts in 3 of 3 runs at start-up withguest protection or unmap range has a hole(10 log lines,FATAL: abort()). The merge changes onlylibScePlayGo/Export.cpp(plus its test and a TechnicalDebt line).maina11c8f7 the abort is replaced by Unreal'sRan out of memory allocating 5565054976 bytes with alignment 65536(I did not look for the commit that turned the abort into this error). With a local one-line change that restores the old chunk check on a11c8f7 (IsKnownChunkreturnschunks.ids.contains(id)again, so chunk IDs outside {0} are rejected when noplaygo-chunkdefs.xmlexists), Sifu runs again in 3 of 3 runs (no abort, no memory error; shader cache hits 3,689 in one run, textures created).playgo-chunkdefs.xml, so the chunk table is not known here. Demon Slayer (Demon Slayer -Kimetsu no Yaiba- The Hinokami Chronicles (PPSA03490 v01.000.000) on Windows: start-up needs seven sceRudp* imports that no library exports; with them it runs until the packed pixel ancillary error (#2548) #3073) stops on the same allocation, but I could not repeat the comparison for it (my runs with older libraries did not start).This is a candidate cause with a reversible test, not a proposed fix: reverting it would affect the title #3238 was written for.
AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Mechanism for the PlayGo cause of this stop, with the trace data and a narrower condition proposed to the author of #3238: #3238 (comment) . In short: Sifu asks about chunk ids one at a time in ascending order until a call fails; the old check fails at chunk 1 (two calls in all), the new one accepts every id (4,023 consecutive ids in a 60 s traced run) and the title's later
Ran out of memory allocating 5565054976 bytesis exactly65536 * 84916(an inference, not traced).AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) on current
maind371ed3 with the old PlayGo chunk check restored locally (one line inIsKnownChunk, not committed; see the mechanism comment above), Windows 10, one 150 s run (the sameapp.exeas in the bisect): no abort, no fatal error, noRan out of memory. The log shows the title mounting its save data (SifuProfile,SifuProfile-1), shader preparation (918 shaders written in one 10 s window, 3,734 misses in all), and only these warnings:unsupported registered shader type 8; it is not prepared at registration(6 lines),its program address is not in the shader registers; preparing it when it is used(3),[gpu] storage image ...: memory no longer registered; N pending ranges dropped(4). I did not see the earlierRenderThreadfree-list fault or theholeabort. What I did not check: the picture, the frame rate, anything after 150 s.So on current
mainthe only start-up stop I can attribute is the PlayGo chunk acceptance from #3238; without it Sifu gets through its start-up and into shader and texture work.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Regression sweep on current
main(ceb342b, plain, no local change; Windows 10, libraries built from that commit, one 60 s run per title under the game lock). Theapp.exeof each title is the one relinked earlier (the relink dates differ; libraries only gain exports, so older relinks load with newer libraries). A single 60 s run cannot judge intermittent faults./app0/..open, no fatal (the chunk enumeration of #3238, see #3209; laterholeabort / allocation error)--module-dir .layout)--module-dir .(#3850); intermittentRenderThreadnullmemcpy(#2724)Job.Workerfault, 25 to 30 % of runs (#3915)unsupported registered shader type 8warningsFAIL: unresolved ELF import WVZBP4IyM+E(setSpecialFloatFormatType)FAIL: unresolved ELF import WkYtyOg30do(libSceVideoOut)sceNpAuthGetIdTokenV3 not implementedlibSceCesCsimports, which load nowstorage image access to depth/stencil surface ... is not implementedLoading.PreloadManager(app.exe+0x7a6730)NGS2: rack id 0x4001 is not implementedkqueue_nid_postfix not implementedOne real regression, already reported (Sifu, #3238). Not covered: pictures and frame rates (log only), runs longer than 60 s, Linux.
AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) follow-up to the regression sweep: the fault at
libc.prx.guest.prx+0x14270is not new on current main, it depends on run length.Same relinked directory, 3 runs each at 60 s and 2 runs each at 90 s, libs from main
ceb342b94vs. current upstream/main (52 commits later):ceb342b94FATAL 0xc0000005,libc.prx.guest.prx+0x14270The fatal appears between 60 s and 90 s on both. My earlier "60 s silent" result was therefore too short to see it; it does not show a regression between the two commits. What the register dump shows: a read of
0xffffffffffffffff(an invalid pointer passed into a libc routine,rbxpoints at adeadbeefcafebabeblock), not a write or memcpy into a null destination, so it does not look like the Hades memcpy signature at+0x141b0. I have not identified the calling guest function, and I have not run the PlayGo-revert variant at 90 s, so I cannot say whether #3238 plays a part.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) crash at
libc.prx.guest.prx+0x14270, narrowed down with gdb (-batch, one run under the game lock, current main libs):int $0x45followed bynop; ud2inside the guest libc functionl3fh3QW0Tss(+3360). That is a deliberate trap sequence, not a bad load or store; the "read of 0xffffffffffffffff" in our report is how the exception is reported for this trap. I could not map the NIDl3fh3QW0Tssto a name (it is not incore, andabort,_Exit,exit,__stack_chk_fail,__cxa_pure_virtual,_exit,longjmp,raisehave other NIDs), so I do not claim which libc function it is.PS5 Out of Memory: AvailablePhysical: 4902486016 UsedPhysical: 9278390272andRan out of memory allocating 5565054976 bytes with alignment 65536(twice,LowLevelFatalError). 5565054976 = 65536 x 84916, the same request as in the fix(libScePlayGo): accept chunk ids when the dump has no chunk definitions #3238 chain (PlayGo chunk enumeration, see my earlier comments). So the fatal exit is the title's own fatal-error path after that failed allocation, not memory corruption.0xdeadbeefcafebabeis our value:__stack_chk_guardincore/libs/prx/libc/src/specifics/gcc/StackGuard.cpp:4. In the dumprbxis the address of that variable (gdb symbol<__stack_chk_guard>) and the stack words are saved canaries. It is not an engine or allocator poison pattern, and it is harmless here. A search of the Sifueboot.binfor the byte pattern finds nothing.Not established: why the OOM fatal only shows up after more than 60 s in my runs, and whether it also appears on a main without #3238 for 90 s (I have only the earlier 60 s revert result). Single title, one gdb run plus four plain 90 s runs.
AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001), where the 5565054976-byte failure comes from. One 100 s run with
APS5_TRACE_MEMORY=1on current main libs (the run ended with the samelibc.prx+0x14270trap), plus host numbers.unmap/map direct/remap fixedcalls. The request of 5565054976 bytes (65536 x 84916) never reaches our kernel as an allocation: the title refuses it in its own allocator and printsPS5 Out of Memory: AvailablePhysical: 4902486016, UsedPhysical: 9278390272first. So there is no error code from us to report for it.allocate physicalcalls are halving chunks (0x12c00000, 0x1b0000000, 0xd8000000, 0x6c000000, 0x36000000, 0x1b000000, ...) that end exactly at physical offset 0x360000000, i.e. oursceKernelGetDirectMemorySizeof 0x360000000 (13.5 GiB), and then it sub-allocates itself. Its Available + Used = 14180876288, about 300 MB below 0x360000000 (14495514624). I did not find where those two numbers come from (no call tosceKernelAvailableDirectMemorySizeis visible in this trace; I only looked at the[memory]lines).app.exeduring the run.What this does not show: why the engine computes 5.5 GB. The earlier bisect ties it to the PlayGo chunk enumeration after #3238 (reverting that one line avoided it at 60 s), but I did not re-run the revert at 100 s with this trace. So: not a limit of ours in the kernel path and not host commit; the number is the title's own, derived from state we provide (PlayGo chunk data, direct-memory size).
Correction (added later): I wrote that no kernel call fails in this trace. That is not supported:
APS5_TRACE_MEMORYprints the arguments of the calls that succeed, not their return values, andsceKernelAllocateDirectMemoryreturnsEAGAINwithout any trace line. So the trace shows which calls were made, not that they all succeeded. I am re-running with return codes logged and will post the result.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) PlayGo revert test at 100 s on current main (
d146ec1b6), local one-line change only (IsKnownChunkreturnschunks.ids.contains(id)as before #3238), not committed; same relinked directory, alternating order:Ran out of memory allocating 5565054976+libc.prx+0x14270fatalceb342b94)With the revert, 3 of 4 runs stay alive for the full 100 s (no fatal, no OOM line; the title reaches shader registration and logs
Shader 0x2008e60000 has unsupported registered shader type 8), one run hits the same OOM and the same trap as main. Without the revert, 6 of 6 runs fail. Fisher exact (6/6 vs 1/4): p = 0.033, two-sided. So #3238 is a major factor for the 5565054976-byte request, but not the only one: it still appeared once with the old check.Reading the code for the numbers in the title's message:
sceKernelGetDirectMemorySizereturns the fixedDIRECT_MEMORY_SIZE(0x360000000),sceKernelConfiguredFlexibleMemorySizeand the flexible total are the fixed 448 MiB (FLEXIBLE_MEMORY_SIZE,core/libs/prx/libkernel/DirectMemory/Export.cpp:37), andsceKernelAvailableFlexibleMemorySizeis that minus image segments and flexible usage. The title'sAvailablePhysical + UsedPhysical= 14180876288 is not the direct size (14495514624) nor direct + flexible (14965276672), so I could not reproduce its sum from our values and do not know which calls it uses.UsedPhysicalof 9.28 GB cannot come from our flexible number (448 MiB total).Limits: one title, 4 + 6 runs, change was a local revert of the check (a test, not a proposed fix, since it undoes the behaviour change of #3238); I did not trace where the 5565054976 is computed.
AI-assisted (Claude Code).
oneandonlydean commentedon Oct 12, 2026
The free-list fault this issue is about is fixed: your runs just before and after #3292 are clean. The out-of-memory stop at start-up is a separate bug, most of it #3238 by your numbers, and PPSA03490 hits it too. Please open an issue for it with the bisect, the chunk trace and the 100 s table, or a PR with the file test you proposed on #3238.
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) trace of the PlayGo and direct-memory calls on current main (
d146ec1b6), 4 runs of 100 s with temporary stderr logging inscePlayGovalidation (ValidateChunks, local only, not committed) and insceKernelGetDirectMemorySize/sceKernelAvailableDirectMemorySize:n=1,first=0,1,2,...) in a loop that never ends while every id is accepted: 7.3-7.8k logged lines per run with a log line every 5000 calls, i.e. about 36-39 million validation calls in 100 s (last counter values 36290000 to 38875000 in the runs where I read it).firstwraps at 65536 (counter 70000 showsfirst=4463), because chunk ids areuint16_t. In those runs the chunk table is undefined, soIsKnownChunkreturns true for every id (core/libs/prx/libScePlayGo/Export.cpp:73).sceKernelAvailableDirectMemorySizeis called 0 times in the 4 runs;sceKernelGetDirectMemorySize4 times at start-up. So the title's "AvailablePhysical" does not come from the largest-free-block call.Ran out of memory allocating 5565054976message or the trap (OOM=0 in all 4), while the same main without logging fails in 6 of 6 runs of 90 to 100 s. The logging changes the timing enough that I could not observe the OOM with the counter, so I cannot say which call count (if any) precedes the failed allocation. I did not test a count limit.What it does show: with the chunk table undefined, the title's enumeration only ends on a failing call, and with the old check (
chunks.ids.contains(id), empty table) the first call fails (3 of 4 revert runs survive 100 s). Whether a bound on accepted ids would fix Sifu is untested.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Hades (PPSA03355, Windows) memory trace around the intermittent
RenderThreadfault (libc.prx.guest.prx+0x13a15, write of 0), current maind146ec1b6,APS5_TRACE_MEMORY=1, 150 s runs, same relinked directory:Failed to allocateline in any run. The title takes 4 GiB, then 256 MiB, 3 GiB and 64 MiB of direct memory (about 7.3 of our 13.5 GiB) and then repeatedly doesallocate physical 256 MiB->map direct->unmap <same address>+0x0(the length printed is 0). Norelease physicalfollows, so each round keeps its 256 MiB (5 to 8 rounds in 150 s).sceKernelMunmapreturnsEINVALfor a length of 0 (DirectMemory.cpp,DoMunmap). shadPS4 (src/core/libraries/kernel/memory.cpp,sceKernelMunmap) and KytyPS5 (source/emulator/src/Kernel/Memory.cpp,KernelMunmap) do the same. These are reimplementations, not console measurements; I found no source for what the console returns.sceKernelMunmap(addr, 0)returning 0 instead ofEINVAL. 150 s runs: with the change 0 of 2 fatal (7 and 8 allocation rounds), plain main 1 of 2 fatal (plus 1 of 3 in the earlier traced runs, so 2 of 5 for main). 0/2 against 2/5 is nothing to conclude from (Fisher p = 0.47), and I am not proposing the change: it would deviate from three implementations without a console source.MemoryPool.cpp) takes one mutex in every method (lock order pool mutex, theng_directLock); I did not find a path where a thread sees "not enough memory" without a failing return. A stress test would not have a failing case to reproduce, so I did not write one.So the 'sizes too small' idea is not supported for Hades (no failing call, about 46 % of direct memory unused at that point), and the failing runs crashed early (after 3 to 5 allocation rounds). Not established: what the title does with the unmap result, and why only some runs end with the null write.
Correction (added later): I wrote that no kernel call fails in this trace. That is not supported:
APS5_TRACE_MEMORYprints the arguments of the calls that succeed, not their return values, andsceKernelAllocateDirectMemoryreturnsEAGAINwithout any trace line. So the trace shows which calls were made, not that they all succeeded. I am re-running with return codes logged and will post the result.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Follow-up to my two memory-trace comments above (Sifu OOM, Hades memory trace), now with return codes. Temporary local build of current main (
2ca6198e9) that prints the result ofsceKernelAllocateDirectMemory,sceKernelMapDirectMemory/MapNamedDirectMemoryandsceKernelMunmap(not committed). Not instrumented:sceKernelMapFlexibleMemory,ReserveVirtualRange,ReleaseDirectMemory,sceKernelMmap-family.Hades (PPSA03355), 3 runs of 150 s, none fatal: all
AllocDMandMapDMcalls return 0. The only non-zero results aresceKernelMunmap(addr, 0)->0x80020016(EINVAL), 4 to 5 per run, one per 256 MiB round. That is the same call I described before; it occurs in these clean runs as well. The failing run I caught earlier (RenderThread fault) was not reproduced with this build, so I still do not know what the title does with thatEINVAL.Sifu (PPSA03001), 2 runs of 100 s, both ending in the
libc.prx+0x14270trap: everyMapDMreturns 0; 18AllocDMcalls return0x80020023(EAGAIN). These are the title's halving probes at start-up: after a 0x12c00000 first block it asks for 0x360000000 (all 13.5 GiB,EAGAIN), then 0x1b0000000 (ok, thenEAGAINfor the same size), 0xd8000000, 0x6c000000, ... down to 0x10000, i.e. it takes everything that is free in power-of-two steps, each size until the first refusal. So the refusals are the title finding the end of the pool, not a failure of a request it needs. NoAllocDMcall with the failing size 0x14bb40000 (5565054976) occurs, so that request is refused inside the title's own allocator before any of these kernel calls (the flexible/reserve paths are not covered by this log).What this changes: the earlier statement that no kernel call fails is now backed by return codes for the direct-memory calls (apart from the
EAGAINprobes and themunmap(addr, 0)EINVAL). It does not explain why the title wants 5565054976 bytes (see the PlayGo comments).AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001) test of a bound on the accepted PlayGo ids when no chunk definition exists: local change only, not committed (
IsKnownChunkreturnsid < 256when the table is undefined, the defined case unchanged), compared with plain upstream/main32e62f2f7, 4 alternating runs of 100 s each, same relinked directory:libc.prx+0x14270trap withRan out of memory allocating 5565054976unsupported registered shader type 8) plus anapp.exefaultSo a bound of 256 does not make Sifu stable: the OOM and the trap still occur in 2 of 4 runs, and plain main also varied (1 of 4 without OOM), which is the run-to-run variation I could not explain earlier. I am therefore not proposing this bound. Facts that matter for any proposal: Guardians of the Galaxy (#3238) needs ids 1 to 10 accepted without a chunk table; Sifu's dump has no
sce_sys/playgo-chunk.dat(the file SleglJan describes in #3238 with 64 to 100 chunks in other titles), so reading the real count from that file, as SleglJan's fork branch does, would not help Sifu either. What would make the PlayGo loop end for Sifu without breaking Guardians is not established.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Sifu (PPSA03001): where the 5565054976-byte request comes from, and a correction to my earlier id-bound test. All on
32e62f2f7, Windows, 100 s runs.The allocation. The title's fatal-error report (
Ran out of memory allocating ... alignment 65536) is called from its allocator; the frame chain of the trap run leads to a container growth routine (app.exe+0x21de26in my relink:movsxd rsi,ecx; shl rsi,4; call <allocator>), i.e. an array of 16-byte elements. 5565054976 B is 65536 x 84916 after rounding up to the 64 KiB allocation alignment, so the requested element count is about 347.8 million; with the title's growth step that means roughly 253 million elements before the growth. Reading this from disassembly only; I did not break in the routine.The cause, measured. With a temporary counter in
ValidateChunks(the check behindscePlayGoGetLocusand the other chunk calls; printed every 10 million calls, not committed), 3 of 3 runs reached at least 250,000,000 calls (last printed value 250000000, the next print at 260000000 not reached) and then ended with the OOM message and thelibc.prx+0x14270trap. That matches the ~253 million elements above. The same title spins onscePlayGoGetLocuswithn=1and an ever increasing id (my earlier trace), because with no chunk definition every id is accepted, and each call seems to add one 16-byte entry on the title's side. That also explains why the earlier logging builds did not reach the OOM within 100 s: they were slower per call.Correction. I reported that a bound of
id < 256for the no-definition case left the OOM in 2 of 4 runs. I now think that comparison used a stale library in some runs (alternating copies into the same work directory; I did not hash them then). Re-run with the library hash checked against the work directory's copy: boundid < 256: 4 of 4 runs without OOM and without fatal for the full 100 s (the title reachesunsupported registered shader type 8in the shader registration, and continues); the bound plus the counter build: another 4 of 4 without OOM, the counter never reached 10 million. Without the bound: 3 of 3 OOM (counter build), plus the earlier 6 of 6.What this supports. For this title the unbounded acceptance of chunk ids when there is no chunk table is the trigger. A bound of 256 stops it; it is an assumption, not a measured console limit (the packages SleglJan looked at in #3238 have 64 to 100 chunks, I found no documented maximum). Guardians of the Galaxy (#3238) needs ids 1 to 10 accepted without a table; 256 keeps that. Not tested: Guardians itself (not in my set), other titles, and the
guest_playgounit test, whose current case expects id0xFFFFto be accepted and would need to change. This is a test result, not a PR.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
State of the PlayGo bound for Sifu (PPSA03001), after the pre-crash runs were repeated:
guest_playgocase, not opened as a PR: https://github.com/xXPBSXx/AnyPS5/tree/fix/playgo-bound-without-chunk-table (e3c0ffc00, one line inExport.cpp, the test, oneTechnicalDebt.mdsentence).guest_playgofails on main with the adapted case and passes with the change; conventions check passes.libc.prx+0x14270trap.sce_sys/playgo-chunk.dat(fix(libScePlayGo): take the chunk set from sce_sys/playgo-chunk.dat #3435,Export.cpp:33-44), but Sifu's dump has no such file, so it falls into the remaining case "no table: accept every id" (IsKnownChunk,Export.cpp:71-74).playgo-chunk.datinto the dump (then fix(libScePlayGo): take the chunk set from sce_sys/playgo-chunk.dat #3435 applies and no bound is needed; I cannot do this, the file is not in my copy of the title); (b) the bound in this branch, with the risk that a title without a table that uses ids of 256 or more would fail; a "highest id requested so far" rule would be stateful and I do not recommend it.scePlayGoGetLocusonly writesout_loci), and what the console returns for an unknown id.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
The change is now open as #4491 (ids below 256 accepted without a chunk table; Sifu, Demon Slayer and Returnal numbers in its description). The chunk count read from
playgo-chunk.dat(#3435) and the Guardians case of #3238 (ids 1 to 10) are unchanged.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Demon Slayer (PPSA03490): the
GameThread timed out waiting for RenderThread after 120.00 secsstop seen once with the PlayGo bound (1 of 3 runs, ended at about 144 s onmainffa198407+ bound). Not reproduced since, so this is what the one saved dump shows and what is not known.RenderThread(named ones includeRHIThread,TaskGraphThread*,PoolThread*,AgcSubmissionThread,AgcInterruptThread,AgcCleanupThread). In the HadesRenderThreadfault of Sifu (PPSA03001): RenderThread faults popping a free list whose head reads 0xFFFFFFFFFFFFFFFF #3209 the same handler printed the name, so the name is set in at least that title. Possible readings: the render thread is not running, or it is among the unnamed ones. I cannot tell which from this dump: the unnamed threads show onlyripandrsp(frame chainrbpis 0), no frames.RHIThreadwaits inlibkernel.prx+0x36475(the same wait as theTaskGraphThread*workers), entered fromapp.exe+0x2db43b8.int 0x45trap, library hash checked) with the PlayGo bound: none of them reached the OOM, the trap, or the 120 s timeout, i.e. the hang did not reproduce under gdb (timing differs); that is 0 of 4 here and 1 of 7 across the bound runs on this title overall (the 3 plain runs and these 4).libkernel(local build) and run until the hang shows up, to see whether the render thread exists in the hung run. Not done.AI-assisted (Claude Code).
xXPBSXx commentedon Oct 12, 2026
Hades (PPSA03355), the intermittent
RenderThreadnull write (libc.prx+0x13a15, about 3 of 8 runs): what the relinked image shows (static,objdumpofapp.exefrommain32e62f2f7, no dynamic proof), and what is still open.memcpy(dst = 0, src = 0x2503b20e0, n = 0x1e10);srclies in the 4 GiB direct-memory window the title maps at0x200000000. The caller is a row-copy loop (app.exe+0x318059, inside the function atapp.exe+0x317bf0), called fromapp.exe+0x30a456.edi), a source buffer (rsi) and a size (edx). It returns early whenrsiis null (test rsi,rsi; je), so the source is non-null here (it is thesrcabove). It then looks the texture up by id ([obj+0xc] == id) in a global vector of 16-byte entries and copies rows into a destination derived from the found object. The destination base being 0 therefore comes from that lookup result, not from the source buffer.0x30a437..0x30a456) checks a local pointer for null before the call and stores it into the node's texture object ([r15+0x18]+0x18), then calls the copy by id. If the copy then finds a different object for that id, or one whose mapped pointer is still 0, it writes through 0. That would fit an intermittent, timing-dependent fault between the thread that creates the texture and the render thread; I did not verify it.sceKernelAllocateDirectMemory,MapDirectMemory,malloc) is involved, and whether it is a race in the title that the console's timing hides. Return codes for the direct-memory calls in 3 clean Hades runs and the Sifu runs are in an earlier comment; none failed exceptsceKernelMunmap(addr, 0).app.exe).AI-assisted (Claude Code).