https://bugs.winehq.org/show_bug.cgi?id=55439
Bug ID: 55439 Summary: RPG Maker game crashes Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: beta60sensei@mail.ru Distribution: ---
Created attachment 74999 --> https://bugs.winehq.org/attachment.cgi?id=74999 WINEDEBUG=+seh,+tid
Hi. I'm playing RPG Maker game and it crashes in some specific places with errors like:
Script 'Flash' line 112: Errno::EBADF occurred. Bad file descriptor - <STDUOT>
The developer of the game says: "seams to be a problem with wine running ingame scripts ... it looks like wine crashes every time I use console output for debugging in scripts".
But, if i run the game with WINEDEBUG, then it works fine without crashes.
There is no errors in terminal when crash occurs, but i will attach log of WINEDEBUG=+seh,+tid of the moment, when the game would crash if it were not running in the debug mode.
I'm using wine-staging 8.13
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- A stab in the dark: might be related to bug 55435.
Though, do fix that gnutls line to clear things up.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #2 from Sensei beta60sensei@mail.ru --- Created attachment 75001 --> https://bugs.winehq.org/attachment.cgi?id=75001 WINEDEBUG=+seh,+tid gnutls fix
Installed lib32-gnutls. It fixed some errors in log, but not crashes of the game.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- ...my personal guess would be that certain values of WINEDEBUG open a console handle regardless of that change.
WINEDEBUG does have its own set of quirks, like the fact that if you set 'server', it's stays set across *all* terminals until you explicitly unset it.
While ruby makers technically aren't console apps, most of their non game-specific code is an embedded ruby interpreter. As the most simple way for scripts to communicate somethings is to print something to stdout, many custom script tend to do exactly that. The way it works on Windows, such output is suppressed *unless* the maker is running in debug mode. wine's way of not opening stdout in the first place might not be the correct approach.
Out of curiosity, mind telling what that script line exactly is ?
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #4 from Sensei beta60sensei@mail.ru ---
Out of curiosity, mind telling what that script line exactly is ?
Here's what the developer said: "From your description it sounds like anything like this causing an issue: print("Scene started \n") ,but I can't say for sure because I can't test it myself. This line of code prints the line of text into console that is only visible in editor, and normally should be ignored by the game."
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- @comment 4:
...actually, you most likely can, quite easily even, given how game data is stored in ruby maker games. But the dev's answer seems to go along my expectations.
I suppose you're unable to test my guess by reverting that commit ?
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #6 from Sensei beta60sensei@mail.ru --- (In reply to Rafał Mużyło from comment #5)
I suppose you're unable to test my guess by reverting that commit ?
No, sorry.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #7 from Sensei beta60sensei@mail.ru --- (In reply to Rafał Mużyło from comment #5)
I suppose you're unable to test my guess by reverting that commit ?
Ok, i think i managed to compile Wine without that commit. Just to be sure i did everything right: i cloned wine git i did git revert -n dcf0bf1f383f8429136cb761f5170a04503a297b (that one from 55435 bug) which returned Автослияние dlls/ntdll/unix/process.c i compiled wine
Now if i use compiled wine, the game does not crash.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- Well, given above, if things were done correctly, it seems that you should now set 'Regression SHA1', CC the author of the commit...and wait.
https://bugs.winehq.org/show_bug.cgi?id=55439
Sensei beta60sensei@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |dcf0bf1f383f8429136cb761f51 | |70a04503a297b
https://bugs.winehq.org/show_bug.cgi?id=55439
Sensei beta60sensei@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- Some semi-related musings on the topic of this regression: before this, sending ^C to terminal of a gui app terminated that app. IMHO, while highly situational, it was a useful feature when needed. While fixing the regression, restoring that feature should be seriously considered.
https://bugs.winehq.org/show_bug.cgi?id=55439
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #10 from Eric Pouech eric.pouech@gmail.com --- a wild guess is probably that after dcf0bf1f383f8429136cb761f5170a04503a297b, the process inheritance mechanism in Wine doesn't clear the inherited handles, which get "random" values... using WINEDEBUG forces the inheritance of the unix fd, which then can succeed when written to
I don't see any Wine related crash in the logs (after installing gnutls), perhaps it's the game that stops when write to output fails? Can you explicit what you mean by "game crashes in specific places"? do you mean it prints & stops, or does it mean it only prints?
To check if the wild guess is correct, can you the game with ./wine game < /dev/null >& /dev/null (you shouldn't get any output, but it could suppress the stops in the execution of the program if they existed)
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #11 from Eric Pouech eric.pouech@gmail.com --- (In reply to Rafał Mużyło from comment #9)
Some semi-related musings on the topic of this regression: before this, sending ^C to terminal of a gui app terminated that app. IMHO, while highly situational, it was a useful feature when needed. While fixing the regression, restoring that feature should be seriously considered.
the Ctrl-C on GUI should have been fixed by b228e3df608e9a6a9fc5df55375974d06324e11e
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl ---
do you mean it prints & stops, or does it mean it only prints?
While I don't have this specific game (its title was never stated), I can give my personal suspicions, based on my own experiences with ruby maker games.
Those scripts are pure ruby with custom RGSS classes for the engine. Sometimes they do reach out to Win32 libs (via the relevant ruby mechanism), but it's relatively very rare.
This script 'debug output' nearly all of the time is simply 'puts' function, that does exactly what's on the envelope - outputs to stdout a string terminated with a '\n'. No waits are involved.
I'm not 100% if I follow the (interpreter's) sources correctly, but it seems ruby's win32 write function - here applied to stdout - is rb_w32_write in win32/win32.c (ruby makers are basically embedded ruby interpreters with some extra bits for sound/graphics output and minimal config management). Obviously, the engine uses a much older version, but the general design should roughly be the same.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #13 from Sensei beta60sensei@mail.ru --- (In reply to Eric Pouech from comment #10)
I don't see any Wine related crash in the logs (after installing gnutls), perhaps it's the game that stops when write to output fails? Can you explicit what you mean by "game crashes in specific places"? do you mean it prints & stops, or does it mean it only prints?
The game window turns black, a new small window appears with a description of the error, and after clicking OK in the error window, the game closes completely.
To check if the wild guess is correct, can you the game with ./wine game < /dev/null >& /dev/null (you shouldn't get any output, but it could suppress the stops in the execution of the program if they existed)
Yes, the game works fine this way.
https://bugs.winehq.org/show_bug.cgi?id=55439
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
--- Comment #14 from Eric Pouech eric.pouech@gmail.com --- thanks for your answers: - from #12 & #13, and looking at ruby's source, a conclusion could be that it's the game that closes itself if the write to output fails... (and not ruby) - as trick in #10 succeeds in #13, it's likely that the cause of the problem lies in "std handles not being cleared out on process inheritance on some options combinations"... the trick in #10 forces the std handles of the first process to be 0, and then inherited by children
A correct fix for this is on my todo list, but I'm afraid it'll take some time to make its way into Wine (if it's ever accepted and it has to touch some sensible areas).
As a temporary workaound, using the trick in #10 or setting WINEDEBUG are viable options
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #15 from Rafał Mużyło galtgendo@o2.pl --- I'd say it's more like ruby throws an (interpreter) exception when it can't open stdout and those few extra engine bits intercept it and print it (well, a formatted part of it) in the popup.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #16 from Sensei beta60sensei@mail.ru --- (In reply to Eric Pouech from comment #14)
As a temporary workaound, using the trick in #10
A question: this trick will not create some big log files on my ssd and/or degrade the game's performance? No downsides to using it?
Thank you.
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #17 from Eric Pouech eric.pouech@gmail.com --- (In reply to Sensei from comment #16)
(In reply to Eric Pouech from comment #14)
As a temporary workaound, using the trick in #10
A question: this trick will not create some big log files on my ssd and/or degrade the game's performance? No downsides to using it?
Thank you.
No (/dev/null is a void sink, so it won't store any content on any of your storages). The only (potential) downside is that you loose all debug messages from Wine.
https://bugs.winehq.org/show_bug.cgi?id=55439
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #18 from Béla Gyebrószki gyebro69@gmail.com --- I ended up here because the same commit causes some of the solitaire games I have installed on Steam fail to launch. E.g. Regency Solitaire https://store.steampowered.com/app/351090/Regency_Solitaire/
The affected games simply quit on launch without an error message or anything striking in the terminal. The games are actually DRM-free so they can be played without Steam running and they all start properly when running outside Steam. It's only when they are started via Steam client that they fail to start.
Reverting commit dcf0bf1f383f8429136cb761f5170a04503a297b or the trick from comment #10 fixes the problem for me.
wine-8.18-127-g6391b8d5c99
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #19 from Béla Gyebrószki gyebro69@gmail.com --- The games I indicated in comment #18 are working again, thanks to commit bf97f9490a6a13b53ca7932ad0313022bc4ceee1. I don't know if this will help in the RPG Maker game reported in this bug report.
wine-8.21-329-gf0c08bd01e6d
https://bugs.winehq.org/show_bug.cgi?id=55439
--- Comment #20 from Eric Pouech eric.pouech@gmail.com --- Sensei: Wine 9.0-rc1 should contain (I hope) a proper fix for the issues you described in #1. Would you mind retesting with wine 9.0. TIA
https://bugs.winehq.org/show_bug.cgi?id=55439
Sensei beta60sensei@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED
--- Comment #21 from Sensei beta60sensei@mail.ru --- Compiled wine-9.0-rc2 and now the game works fine without crashes. Thank you.
https://bugs.winehq.org/show_bug.cgi?id=55439
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.0-rc3.
-
WineHQ Bugzilla