JUMANJI: The Video Game (PPSA03973)

[JJenkx]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

JUMANJI: The Video Game (PPSA03973)

Content version tested

01.000.001

AnyPS5 commit

main 44a59edc3a.

System tested

Linux 7.2.9 (Arch), Ryzen 9 7950X, Radeon RX 6650 XT, RADV Mesa 26.2.4, GCC, Release.

Furthest point

Menus (start-up logos and legal screen)

What is shown

From a fresh save, with Cross pressed every 15 s for 180 s:

• It shows the Funsolve and Columbia Pictures logos, then the legal screen (Unreal Engine 4, Columbia Pictures, Outright Games, Funsolve).
• It stays on that legal screen from about 95 s to the end, at about 3 FPS (one sample at 0.4). No driver stop.

The log shows the host-import budget collapsing after vkAllocateMemory fails with -1000072003 (VK_ERROR_INVALID_EXTERNAL_HANDLE) 15 times: it is lowered to 21.4 MiB, then to about 72 MiB. At shutdown, 323,506 imports had been refused and 89 made. That is the pattern draft #8091 addresses.

With #8091 this title runs much faster and gets further, but it then crashes intermittently. That PR stays a draft for it: #8091 (comments from 2026-10-22 on).

Current blocker

Host-import budget collapse after -1000072003 failures leaves it at about 3 FPS on the legal screen. With #8091, an intermittent crash.

How it was run

relinker --registry --rpath <build>/core/libs/libs eboot.elf app.elf

Modules in sce_module are converted with the title. The dump has its PlayGo files, so no PlayGo setting was used.

AI-assisted testing and report: yes, Claude Code.

[JJenkx]

Update on newer main 801d5b9bc1: no longer slow, but it still does not get past the start-up screens. Same machine, dump and setup as the first report.

The host-import budget is no longer lowered. There are still about 2,300 vkAllocateMemory failures with -1000072003 per 150 s, but they are interleaved with successful imports, about 5,200 made. The start-up screens now run at about 33 FPS, against about 3 before.

In a 300 s run, with Cross pressed every 15 s and screenshots every 30 s, the title cycles through the intro and never reaches a menu:

• The Funsolve logo is showing at 30, 60, 90, 120, 150 and 210 s.
• The Outright Games logo is showing at 180 and 240 s.
• The legal screen is showing at 270 s.
• About every 60–90 s the frame rate dips to 2–8 FPS for a few seconds, which looks like loading (lows at about 64, 154, 215 and 275 s).

There was no crash and no driver stop in this run, nor in two earlier 150 s runs on the same build. The log shows no unimplemented-function errors, and nothing obvious at the points where the intro restarts.

Furthest point: unchanged (start-up screens). Current blocker: the intro repeats instead of reaching the title menu; the cause is not established.

AI-assisted: yes (Claude Code).

[JJenkx]

Follow-up to my previous comment: the repeating intro was caused by my input, not by the title. Same build (main 801d5b9bc1) and setup, 300 s with no input, screenshots every 30 s:

• The Columbia Pictures logo stays on screen from 30 s to 120 s.
• The Funsolve logo shows at 150 and 180 s.
• The legal screen shows from 210 s to the end at 300 s.
• About 33 FPS until about 200 s, then 9 to 20 FPS on the legal screen.

No crash and no driver stop. So without input the intro plays through once and stops on the legal screen, as in the first report. It does not loop. Pressing Cross every 15 s is what made it go round again.

Furthest point: start-up screens (legal screen). Open questions: why the Columbia Pictures logo stays for about 90 s, and why the title never leaves the legal screen.

AI-assisted: yes (Claude Code).

[JJenkx]

Correction to my two previous comments (19214339 and 19214490): the build I called main 801d5b9bc1 was not main. Its graphics driver was the previous head of draft #8091 (the host-import ceiling pin gated on OOM codes), built on 801d5b9bc1. I made a mistake assembling that test build.

So read those two comments as 801d5b9bc1 with #8091's earlier head, not as main:

• about 33 FPS on the start-up screens and no budget lowering;
• with no input, the intro plays once and stops on the legal screen;
• pressing Cross every 15 s makes the intro repeat.

The faster start-up and the absence of budget lowering come from that PR's change, not from newer main. For real main, my first report (on 44a59edc3a) is the latest data: about 3 FPS on the legal screen after the budget collapses. I have not rerun JUMANJI on a correctly built newer main.

AI-assisted: yes (Claude Code).

[JJenkx]

Real-main data, as promised in my correction above: main 801d5b9bc1, with its graphics driver built from exactly that commit. Three 150 s runs with Cross every 15 s.

• The title crashes at about 30 s in all three runs (segfault, exit 139), during the start-up screens.
• Before each crash, the host-import budget is pinned at 77 MiB (the host heap reports about 50,900 MiB), and about 2,900 imports have been refused.
• The log then reports a WAIT_REG_MEM timeout on queue 0x20, after which the process segfaults.

On the older main of my first report (44a59edc3a), it did not crash; it stayed at about 3 FPS on the legal screen. With draft #8091's current head, the same runs reach the start-up screens at about 33 FPS without crashing (three of three): see comment on #8091.

Furthest point on main: start-up screens. Current blocker on main: a crash at about 30 s after the import budget collapses; the cause is not established.

AI-assisted: yes (Claude Code).

[JJenkx]

Current-main recheck of JUMANJI (PPSA03973) on 381891927c. Linux 7.2.11, RX 6650 XT, RADV Mesa 26.2.6, Release.

Setup:

• Relinked with relinker --registry --rpath <build>/core/libs/libs eboot.elf app.elf.
• Run with APS5_PLAYGO_UNLISTED_CHUNKS=absent.
• Input: Cross every 15 s, as in my earlier runs.

main no longer crashes. The about-30 s segfault after the WAIT_REG_MEM timeout that I reported on 801d5b9bc1 is gone:

• Stability: one 177 s run ends at the scheduled close with exit 0, no WAIT_REG_MEM timeout, and no "budget lowered" message.
• Frame rate: 33 to 35 FPS, with dips to about 18 to 20.
• Furthest point: still the start-up screens. The intro (Funsolve and the other logos) keeps repeating under Cross, as before.

Host imports. 2,383 of them fail at vkAllocateMemory with VK_ERROR_INVALID_EXTERNAL_HANDLE and fall back to copies; none are refused for budget. That is the scattered direct-memory case #4449 imports as a run list. With #4449 (2f225f0ff2) merged onto the same main:

• 0 failures;
• 36 to 40 FPS, with dips to 9 and 22;
• the same intro loop, exit 0.

That is one run per arm, so it does not establish a speed difference.

Not verified: getting past the intro, for example with no input or with Options; audio; other GPUs.

AI-assisted analysis: yes.

[JJenkx]

Recheck on plain main 88e804b0a7 with no other PRs, after #4449 and #6959 merged. RX 6650 XT, RADV Mesa 26.2.6, Linux, APS5_PLAYGO_UNLISTED_CHUNKS=absent, 240 s with scripted Cross, then forward stick.

Result: it exits 0 at 232.9 s, with a median FPS after 60 s of 38.89 and 0 failed host imports. Mean screenshot brightness (0 to 255) at 60, 150 and 225 s is 15.0, 15.0, 15.0. At 150 s the title is still on its legal and logo screen (the same intro loop as in my earlier runs), so this run does not reach gameplay.

AI-assisted: yes (Claude Code).

[JJenkx]

More on the intro loop, on plain main 88e804b0a7.

• Input does not help. Options, Cross, Circle, Triangle, Square and the touchpad, pressed in turn from 40 s to 160 s, change nothing. The sequence keeps cycling Columbia Pictures, Funsolve and the legal screen.
• PlayGo does not help either. With APS5_PLAYGO_UNLISTED_CHUNKS=installed instead of absent, the screen stays on the Funsolve logo at 65, 125 and 185 s.
• The save is read normally. The save data mounts, /savedata0/ue4savegame.dpx.sav opens, and the save unmounts.

After that, the title opens no further file through sceKernelOpen and starts three worker threads. Unreal Engine 4 repeats its startup movies as the loading screen until the first map has loaded, so this looks like a load that never finishes, not a missing input. One caveat: pak reads may go through APR, which is not logged here, so the missing echo-ps5.pak open is not proof that the pak is never read. Every run exits 0 at the scheduled close.

AI-assisted: yes (Claude Code).

[JJenkx]

Narrowed the intro loop on plain main 88e804b0a7, using APS5_TRACE_APR and a gdb thread dump at 90 s. Addresses are in the relinked executable; code at virtual 0x400000 is at file offset 0x4000.

• Loading starts and then stops requesting new data. The pak is read through APR: about 48,800 reads of echo-ps5.pak in 112 s. In the first three quarters of the run nearly every read is new data from across the pak. In the last quarter no new offset is read; the same roughly 2,300 offsets, the startup movies, are read over and over. APR keeps serving those reads to the end, so its queue is not blocked.
• The main thread is waiting for the async loader. Thread 1 sleeps through sceKernelUsleep (return address 0x1572dd9) in a loop that tests a global byte at 0x767f488, calls two helpers and sleeps through 0x1286620 on each pass. The only writes of 1 to that byte are at 0x156b81b, 0x156b936 and 0x156c036, and each is followed by a reference to the UTF-16 string FAsyncLoadingThread. This looks like Unreal's wait for asynchronous loading to finish.
• Three more threads poll with sceKernelUsleep. One of them, return address 0x2becde3, repeatedly reads a 32-bit status word at 0x10(%rbx) between mfences, together with a byte at 0x88(%rbx). Neither changes.
• Ruled out before this: input, PlayGo (absent and installed), trophies and UDS (synchronous here, and the UDS event is posted normally), NP async polls (they finish at once as signed out), and the save data (mounted, read and unmounted normally).

Next step: find what writes that status word, to see which completion the loader is still waiting for.

Can't Drive This (PPSA02743), a Unity title, shows the same symptom on the same main: two guest threads sleep-polling in sceKernelUsleep while the loading bar stays empty. Both may be waiting on the same kind of completion.

AI-assisted: yes (Claude Code).

[JJenkx]

Correction to my previous comment: the thread polling at 0x2becde3 is not what the loader waits for. A gdb attach at 90 s found its object at rbx. The 32-bit word at +0x10 is 0. The object starts with a pointer into read-only data (a vtable) and holds several doubles, and the loop around 0x2becde3 computes a sleep time from them. So it is a periodic timer thread that sleeps and checks a stop request, which is normal. A hardware watchpoint on that word could not be kept: the process ended with SIGSEGV after it was set, because AnyPS5's write watching uses SIGSEGV.

What still holds: the main thread is in the loop at 0x1572dd9 around the FAsyncLoadingThread flag, and no new pak data is read once the startup movies start looping. Which completion the loader is waiting for is not identified yet.

AI-assisted: yes (Claude Code).

[JJenkx]

Follow-up on the async-loader stall.

Current main f06d7fdcee (268 commits newer, including 10ecaba5da7, the queue-0 worker fix that cleared a loading stall in Contra): unchanged. 240 s with Cross/Options presses: the legal screen at 60 s, the Outright Games logo at 150 s, the legal screen again at 230 s. 28 file opens, the last the save read (ue4savegame.dpx.sav), exactly as before. Exit 0 at the scheduled close.

Where the threads wait (gdb frame-pointer walk at 90 s on 0278ca9831 + #14298, 132 threads; offsets are addresses in app.elf, text at 0x400000):

• Main thread: a timed FEvent wait reached from the engine tick (0x403afd, the function that references EventWait/Slate and DeferredTickTime), so it is waiting on the render thread.
• One thread waits via 0x12a446b ← 0x40dafa ← 0x1c06782; that last function references CreateVertexBuffer_RenderThread, CreateIndexBuffer_RenderThread and CreateStructuredBuffer_RenderThread, so it is waiting for a render-thread resource command (consistent with the loader creating buffers).
• 21 pool and 13 task-graph threads idle in FEvent::Wait (0x12ed5cc). A usleep poller (0x127ff90, FPlatformProcess::Sleep in a running-flag loop) is a heartbeat and not involved.

Also checked: APR waits never spin (a local diagnostic logged no wait lasting even 5 s), AnyPS5's AIO completes before returning, the AMPR event registration matches the APR trigger, and AnyPS5's Linux condition variable cannot lose a wakeup with the mutex-protected FEvent pattern. So the render-thread work these threads wait on never runs, for a reason I have not identified; it needs Unreal's task graph decoded from the stripped binary.

AI-assisted: yes (Claude Code).