Crash while playing Kid Icarus Uprising in canary build

I’ve been playing Kid Icarus Uprising on one of the latest canary builds (it now finally runs). After a certain period of time, usually a few minutes, the game crashes suddenly, always throwing up the following error at the end of the log:

[1074.460854] Kernel core/hle/kernel/handle_table.cpp:Create:27: Unable to allocate Handle, too many slots in use.
[1074.460862] Debug ./core/hle/result.h:operator():397: Assertion Failed!
Tried to Unwrap empty ResultVal

Note: this same crash and error also occurs on a lot of unofficial builds as well.

System Information

  • Operating System: Windows 10
  • CPU: Intel I5-8250
  • GPU: integrated
  • Citra Version (found in title bar): Citra Canary #796
  • Game: Kid Icarus: Uprising
  • Screenshot of Issue (include the full Citra window including titlebar): n/a (game freezes, citra force quits itself immediately)

Diagnostic Log
Upload your log file as an attachment by dragging & dropping.
citra_log.txt (42.8 KB)

I found some issues in that log that need resolving:

is there a specific point where the game crashes?

Not exactly, but its usually after about 10-15 minutes in. Rather annoying since most levels take about 15 mins to complete.

my quick solution is resize handle_table value at


@line: 96

* This is the maximum limit of handles allowed per process in CTR-OS. It can be further
* reduced by ExHeader values, but this is not emulated here.
static const std::size_t MAX_COUNT = 4096;


static const std::size_t MAX_COUNT = 16384; /4 x 4096/

and rebuild citra following:
with: MinGW-w64 Build with MSYS2

after this patch, I test play 3 chapter, no crash so far

Could you do me a favor and upload this build somewhere? I don’t have time to find out why my citra is failing to compile right now.

I’ve tried some custom builds that include the “fix” for this but they both cause the get tons of slow down probably due to some other fixes. I’d get a lot of benefit from a build that only changes that one value and nothing else.

We don’t provide support for unofficial builds here. Really, this issue should be properly documented via a new GitHub issue.