https://bugs.winehq.org/show_bug.cgi?id=52037
Bug ID: 52037 Summary: MaiDenSnow Eve trial crashes upon entering load menu Product: Wine Version: 6.19 Hardware: x86-64 URL: https://trial.dlsite.com/doujin/RJ116000/RJ115762_tria l.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
I'm reporting against 6.19, but IIRC this predates 6.0.
I have no proof that the problem stems from the code in win32u/gdiobj.c, as gdb backtraces report stack being corrupted. Yet after changing the warning in handle_entry to print handle value, I can see the handle (font) being accessed after being freed by free_gdi_handle. Also, 'all,-heap' somehow sidesteps the crash, for a price of a major slowdown. The crash is 'illegal instruction', so once again, stack corruption.
To reproduce:
- run the trial - pick the last option (fourth) in the menu - pick 'New Game' - go with the first option in the next menu - as the game starts, access menu (press X) and save (first option) - press F12 to quickly restart the game - back at the title screen pick 'Load Game' - ...get the crash
(if at any point you get a splash screen with some text and a clock image, you need to press 'up,left,up,down,right' on the keyboard)
https://bugs.winehq.org/show_bug.cgi?id=52037
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|MaiDenSnow Eve trial |MaiDenSnow Eve trial |crashes upon entering load |crashes upon entering load |menu |menu (use after free ?)
https://bugs.winehq.org/show_bug.cgi?id=52037
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- ...so, it's a bit more complicated. I might have misread the log.
The part with invalid font handle seems to be the main font thread that appears in the log only after the game closes. In the thread that crashes it's a bitmap handle - first it gets freed, then NtGdiCreateDIBSection is called and a new bitmap handle gets the just freed entry.
For some reason this time it doesn't work - in the log it's not the first time such sequence happens.
Though given it's a stack corruption, it's just reading tea leaves - it could have been broken for awhile, but nothing of importance was accessed.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...well, main font thread or simply the standard crash dialog...
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- As a minor update: with wine 6.22 + patch 220144, the crash still happens.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #4 from Sagawa sagawa.aki+winebugs@gmail.com --- Hi Rafał,
From my viewpoint, I can't reproduce the issue with wine 6.22 + patch 220144.
I can enter the load screen after the save and continue the game.
My locale is ja_JP.UTF-8, i.e. LANG=ja_JP.UTF-8. What locale do you use? Could you attach WINEDEBUG=fixme-dmime,font debug log?
https://bugs.winehq.org/show_bug.cgi?id=52037
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #5 from Rémi Bernon rbernon@codeweavers.com --- It may have been fixed with 39fea6cd1eb175cddf3cbccc1fd09fec48da881e, if I read the initial description correctly?
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 71093 --> https://bugs.winehq.org/attachment.cgi?id=71093 fixme-dmime,font log
@comment 5: as per comment 2, it obviously isn't.
@comment 4: the locale used *is* ja_JP.utf8; as for the other part, given that this is timing dependent, two things may play a role: my set of fonts and that I'm still on non-mingw build.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- ...that was meant to be "as per comment 3"; also, as I've said in comment 2, other gdi handles might be involved - if that last part of the log is for the crash dialog, then the earlier are bitmap/region handles.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 71105 --> https://bugs.winehq.org/attachment.cgi?id=71105 gdi,dib,bitmap,font,dc,region log
For comparison, a log containing more handle traces.
To clarify, 'handle_entry handle value' traces are extras added for 'printf debugging' - they are printed when handle_entry (in win32u/gdiobj.c) returns that handle.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- ...explicitly, they're
TRACE("handle value %p, unique 0x%x\n", handle, gdi_shared->Handles[idx].Unique);
On that note, logs would be a bit easier to grep if the style for pointer printing was kept consistent - now sometimes it's prefixed with '0x', sometimes not (though not that I've kept it consistent either).
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl --- If someone here has an idea for a minor code change that would help to narrow down the problem more than the last log does, I'm open for reasonable suggestions. Though given that it's a stack corruption and by gdb output seems to happen in wineserver, this might be tricky - my debugger skills are quite low, likely insufficient for chasing down a locking problem. (only idea that comes to me would be a TRACE on locking/unlocking gdi_lock, but that seems too noisy)
Also, that aquafont/aquapfont pair in the log are sometimes quite nasty neighbors (for example, one of them tends to get picked in a chromium based browser (without any good reason) on some of the pages, making them very difficult to read (especially if you don't really know the language in the first place)), but fortunately in wine apps seems to be ignored.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl --- I've made no progress since - still crashes with 7.2.
https://bugs.winehq.org/show_bug.cgi?id=52037
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl --- So, I've got a few very impolite things to say.
So, I've just tested this with 7.4 (haven't tried 7.3) and it started to work (even though the initial menu delay is high).
Why am I pissed though ?
Because I'm close to certain, that given comment 4, this wasn't due to any change in wine. What did change was that I grudgingly switched to a mingw build due to testing a different bug and while it made no noticeable difference for that bug, it 'fixed' things here.
FFS, this game isn't using anything special. It's dll loading code is pure standard old ruby calls. Why does mingw switch affects anything here ?
(also, during that other bug, I've learned that relay results might be misleading, so this might be something more complicated than a simple race)
https://bugs.winehq.org/show_bug.cgi?id=52037
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|MaiDenSnow Eve trial |MaiDenSnow Eve trial |crashes upon entering load |crashes upon entering load |menu (use after free ?) |menu with non-mingw build
-
WineHQ Bugzilla