[Bug 52593] RPG Maker MV: Crash in bundled qt5webenginecore on project open

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52593

--- Comment #1 from Zoë Sparks <zoe at milky.flowers> ---
The following rough and hacky procedure doesn't prevent the crash, but it does
delay it for a significant amount of time in my environment (maybe a couple
minutes?). I found it on "accident" while trying to get more detailed logs
around the crash.

1. From a fresh installation of MV, start it up with `WINEPREFIX=[PREFIX] wine
'C:\\Program Files\\KADOKAWA\\RPGMV\\RPGMV.exe'`.
2. Press "Continue" when you see the registration screen and wait.
3. Once you can use the program, create a new project. MV will crash a few
seconds after the project is finished. The project itself will still be there;
the crash occurs after project creation fully completes.
4. Make a FIFO (e.g. `mknod /tmp/wine_rpgmv_debug p`).
5. Edit the `projectFileUrl` registry key in `[Software\\KADOKAWA\\RPGMV]` and
give it a blank string value.
6. Start the program with `WINEPREFIX=[PREFIX] WINEDEBUG=+seh,+relay wine
'C:\\Program Files\\KADOKAWA\\RPGMV\\RPGMV.exe' &>/tmp/wine_rpgmv_debug`.
7. Attach the read end of the FIFO to /dev/null (i.e. `cat /tmp/debug_log >
/dev/null`).
8. Press "Continue" when you see the registration screen and wait for MV to
start up.
9. Once it's up, open up the project open dialog to open your just-created
project, but don't actually open it yet.
10. Stop sending the wine/MV output to /dev/null and instead redirect it to a
file, ideally a file on a slow HDD with a lot of space as it will write several
GB of text quickly. The point is just to slow the wine process down as much as
possible. There are certainly more elegant ways of slowing Wine down than this
if it's truly needed (patching Wine with some time-wasting junk code in the
right place for example)—I'm mainly recording this process for the sake of
having a record.
11. Actually open the project.
12. Once it's open, wait a bit, then stop sending the wine/MV output to your
scratch file and instead send it back into /dev/null.
13. You should have a couple of minutes in which you can actually use MV
almost-normally before the same type of crash occurs (the backtrace is
identical etc.). It's pretty responsive with the output sent to /dev/null and
everything seems to work properly during that time. The only thing that was a
bit wonky is I found that if I tried to launch the project, nothing happened at
first, but after the main editor crashed the game process would actually start
up, perhaps just because of the extensive overhead introduced into the project
start routines by all the logging. The game ran fine though after that point.

I wish I could say whether or not this is due to some periodic qt5webenginecore
thread that's launched every so often by MV, such that the earlier crash
shortly after opening a project is "dodged" by this procedure, or if it's the
"same" crash that's merely delayed by the logging overhead.

I have yet to actually see the crash with +relay on, which is unfortunate. It
may occur eventually, but if I'm actually redirecting the output to a file I
run out of hard drive space before I see a crash. It's possible that the
extreme slowness induced by +relay and output to a file on disk prevents the
crash somehow, but also that it would still occur eventually if I waited long
enough. The best logs I've gotten so far are with
`WINEDEBUG=+seh,+tid,warn+all`, but although I can see the crash I have yet to
make much heads or tails of them beyond that. You still end up with around 8G
or so of log.

One idea I had was to try to cross-compile a debug build of the same version of
Qt5 MV is using and drop in the relevant libraries from that, but (a) I'm not
quite sure which Qt5 it's using yet and (b) cross-compiling Qt5 is its own
wacky adventure, as I found out. Still, this strategy may yet yield fruit.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.