This could cause a crash and was previously fixed by 3aa39867, but
it's a band-aid solution. This fix addresses the underlying bug that
actually causes the crash.
The workaround remains in place for now because similar bugs related
to NaNs have been encountered, and it's not currently known how many
places in the codebase are affected as well.
The last argument is used as a char*, so we need to explicitly
pass nullptr instead of 0 to ensure it has the correct type.
This was causing crashes due to va_arg reading 8 bytes when only 4
were provided by the caller - if the out-of-bounds bytes are
non-zero, the null check fails and it continues pulling args from
beyond the argument buffer potentially triggering a segfault.
The framebuffer size flows into Aurora as follows:
Into JUTVideo:
AURORA_WINDOW_RESIZED handler ->
mDoGph_gInf_c::setWindowSize ->
JUTVideo::setWindowSize
From JUTVideo -> dComIfG_play_c:
fpcCt_Handler ->
phase_4 ->
dComIfGp_setWindow
From dComIfGp_play_c -> Aurora:
mDoGph_Painter ->
drawDepth2 ->
GXSetTexCopySrc ->
GXCopyTex ->
aurora::gfx::resolve_pass (called by GXCopyTex)
The trouble is that 1) phase_4 is only called when creating a new scene/room,
and 2) even when it is called, mDoGph_Painter is executed before fpcCt_Handler
in the main loop so the new size isn't visible to aurora::gfx::resolve_pass
until one frame after it's set. This causes a crash due to the original size
being passed to CopyTextureToTexture despite the destination framebuffer now
being smaller.
As a workaround, we just cut out the whole middleman section and call
dComIfGp_setWindow immediately when we receive a resize event. This way the new
size is immediately visible to Aurora.
YunataSavior