Conversation
state_data was a local array, so the char* this function returns pointed at stack memory already invalid by the time the JS side (emulatorjs.js's saveStateInfo cwrap, return type "string") read it via UTF8ToString(). JS never frees the buffer despite the comment claiming it does, so this also isn't a heap-allocation-without-free situation -- making it `static` is both correct and leak-free. Symptom: every single save-state attempt (success or failure) logged garbled, non-ASCII console output instead of the intended status message, and the frontend reported "FAILED TO SAVE STATE" even once the underlying core's retro_serialize()/retro_serialize_size() worked correctly. Assisted-by: Claude:claude-sonnet-5
platform_emscripten_get_canvas_size() returned early when either width or height was non-zero, so a partially published canvas size returned the zero one to the caller instead of falling back. Both dimensions are written together in practice, so this has not been observed to bite; the guard is simply wrong as written. Unchanged at cold start: both values really are zero before the page publishes them, so the fallback and its message still fire once there. Same fix in both the emscripten and emulatorjs platform drivers.
…tent platform_emscripten_update_canvas_dimensions_cb() stores width and height as two separate atomic stores. Each is atomic; the pair is not. Under HAVE_THREADS the reader runs on the emulator thread, so it can observe the new width alongside a stale zero height. platform_emscripten_get_canvas_size() then returned early -- its guard was `width != 0 || height != 0` -- handing the caller a zero height, which is used to compute geometry and produces a wrong aspect ratio. Intermittent by nature, and not specific to any core. Store height first and width last, making width the release point: a reader that sees a non-zero width is guaranteed to see the matching height. The reader already loads width first, which is the matching acquire order. Also require both dimensions before skipping the fallback, so a zero can never be returned even if the store order is broken again later. Both platform drivers carry the same code and the same bug.
ScummVM fetches its engine data over the network during game load: LibretroRemoteEngineData::fetch() sits in the engine search path and calls emscripten_wget_data(), which is synchronous. Built without ASYNCIFY that blocks the main thread and the load never completes. Assisted-by: Claude:claude-opus-5
TRusselo
marked this pull request as draft
September 21, 2026 01:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ScummVM fetches its engine data over the network during game load.
LibretroRemoteEngineData::fetch()is registered in the engine search path and callsemscripten_wget_data(), which is synchronous:emscripten_wget_data(url.c_str(), &buffer, &numBytes, &error);Engines pull
fonts.dat,toon.datand similar from there whileretro_load_game()is running, so without ASYNCIFY that call blocks the main thread and the load never completes.Same shape as
bluemsxin ad2ca2a — a core doing synchronous I/O during load.One line, no behaviour change for any other core.
AI assistance: written with Claude, reviewed and tested by me before opening.