The progress dialog server only leaves its loop when the counters match AND
g_progr_text is empty. That text is refcounted across nested progress scopes, so
a leaked reference leaves the loop spinning forever: the dialog is never closed,
and the cleanup that resets g_progr_ptotal never runs either, which is what
ppu_thread::cpu_task waits on before switching to overlay-message mode.
Seen on device with a fully booted, running game sitting behind a "Building SPU
Cache... 941 of 941" dialog for over ten minutes. The RSX thread and two SPU
threads were at 97%, syscall counters were climbing, and nothing had compiled
since six minutes in. Note the label is stale in that state: the server only
overwrites its cached text when it receives a non-empty one, so the last
meaningful message stays on screen and says nothing about which scope leaked.
Closes the dialog once the counters are complete and have been completely idle
for roughly five seconds. wait_no_update_count resets on any change to any
counter or to the text, so work in progress can never reach the threshold. The
warning names the held text, which is what will identify the leaking scope.
This is a safety net. The reference leak itself is still there.