https://bugs.winehq.org/show_bug.cgi?id=47651
Bug ID: 47651 Summary: PlayOnline Viewer: Page fault on read access at launch time. Product: Wine Version: 4.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: escomk3@hotmail.com Distribution: ---
Created attachment 65092 --> https://bugs.winehq.org/attachment.cgi?id=65092 Wine Output with the Page Fault
After commit c5577721 [1], PlayOnline Viewer will crash soon after having been launched (before any graphics get drawn).
A fix may have been staged already, since with 4.14 Wine Staging the issue does not seem to be triggered, but I have not yet tested if Staging was affected at any point between 4.11 and 4.14.
1. https://source.winehq.org/git/wine.git/commit/c5577721b909f8c70d3723cae561e9...
https://bugs.winehq.org/show_bug.cgi?id=47651
Chiitoo escomk3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Gentoo Regression SHA1| |c5577721b909f8c70d3723cae56 | |1e9594902df26
https://bugs.winehq.org/show_bug.cgi?id=47651
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |hverbeet@gmail.com, | |jzeng@codeweavers.com, | |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #1 from Matteo Bruni matteo.mystral@gmail.com --- Assuming this is still an issue, can you attach a +ddraw,d3d trace?
Is there a free download of this application?
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #2 from Chiitoo escomk3@hotmail.com --- (In reply to Matteo Bruni from comment #1)
Assuming this is still an issue, can you attach a +ddraw,d3d trace?
Is there a free download of this application?
It seems I'll need to do some more digging.
There is a free download, but as I was verifying if one can get far enough for the crash without an account, I noticed that I can't get it to crash in the test install (earlier I had assumed a little that one needs to update the software before it starts crashing, but that does not seem to be the case).
I have two different installations in different prefixes, which both have the issue, and should be quite clean from workarounds. They are old, however, so there might well be something I'm forgetting, and something that isn't visible via 'winecfg' or 'winetricks.log'.
Once I have verified (more) if this happens or does not happen in a really clean prefix (and after a full install of Final Fantasy XI on top of the PlayOnline Viewer), I'll send an update.
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #3 from Chiitoo escomk3@hotmail.com --- Yeah, I think this can be closed for now at least.
I still don't know what it is with those two prefixes, and why the issue happens with only the specific commit reverted (or by not using Staging), but it does not happen in a really clean prefix and a new install of the application even after updating it.
I probably skipped some testing due to having found a commit that made a difference (though it didn't look like one that should), so apologies for that!
https://bugs.winehq.org/show_bug.cgi?id=47651
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #4 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Chiitoo from comment #3)
Yeah, I think this can be closed for now at least.
I still don't know what it is with those two prefixes, and why the issue happens with only the specific commit reverted (or by not using Staging), but it does not happen in a really clean prefix and a new install of the application even after updating it.
I probably skipped some testing due to having found a commit that made a difference (though it didn't look like one that should), so apologies for that!
It might be possible that the application on first run selects a depth buffer format (which happens to be WINED3DFMT_D32_UNORM if available), saves it in some configuration file and proceeds to crash and burn on following runs if it's not available anymore.
Resolving INVALID for the time being, thanks for reporting the bug and feel free to reopen it if new info comes to light.
https://bugs.winehq.org/show_bug.cgi?id=47651
Chiitoo escomk3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED
--- Comment #5 from Chiitoo escomk3@hotmail.com --- (In reply to Matteo Bruni from comment #4)
It might be possible that the application on first run selects a depth buffer format (which happens to be WINED3DFMT_D32_UNORM if available), saves it in some configuration file and proceeds to crash and burn on following runs if it's not available anymore.
Resolving INVALID for the time being, thanks for reporting the bug and feel free to reopen it if new info comes to light.
That does seem plausible, and makes things make more sense to me, too.
I gave it a go with Wine 4.11, installing the PlayOnline Viewer in a clean prefix, then after the first start, launching it with 4.17 will indeed produce the error.
However, if I use 4.17 for the first start, then 4.11 will work as well (and 4.17 keeps working after that too).
The traces seem to be talking about 'WINED3DFMT_D32_UNORM' quite a bit too.
Example steps to reproduce (no subscription needed):
1. Download the installer files ( http://www.playonline.com/ff11eu/download/media/install_win.html ). 2. Run 'FFXIFullSetup_EU.part1.exe'. 3. Run 'FFXISetup.exe'. 4. It will be enough to select the 'PlayOnline Viewer' only for installation. 5. Run 'pol.exe' using Wine 4.11 (or with the discussed commit reverted). 6. Close the PlayOnline Viewer. 7. Run 'pol.exe' again using Wine 4.17 (or without reverting the commit).
Re-opening for now, as this does seem like rather unwanted behaviour.
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #6 from Chiitoo escomk3@hotmail.com --- Created attachment 65334 --> https://bugs.winehq.org/attachment.cgi?id=65334 Trace (d3d,ddraw) With Wine 4.17 After Wine 4.11
https://bugs.winehq.org/show_bug.cgi?id=47651
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #7 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.17?
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #8 from Chiitoo escomk3@hotmail.com --- This does still seem to happen at 'wine-5.17-138-g05d9df73d12d2', though it is possible it's now a different issue, as the output is a bit different:
wine: Unhandled page fault on write access to 00007F49361B45E0 at address 00007F4936394B20 (thread 0094), starting debugger... ^C00a0:err:module:DelayLoadFailureHook failed to delay load comctl32.dll.InitCommonControlsEx wine: Call from 000000007B03057F to unimplemented function comctl32.dll.InitCommonControlsEx, aborting 00a0:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr (nil) 00a8:fixme:console:default_ctrl_handler Terminating process 20 on event 0
The debugger never manages to do its thing.
This was tested going by the steps I've mentioned in Comment 5, mostly... I can not currently compile 4.11 (possibly due to too new GCC or something else I'm not going to investigate), but I happened to have the previously compiled binary package still around. Moreover, reverting the mentioned commit does not seem to be a simple task any longer either.
I'm not sure how much we should care if this is the only way the issue is triggered, even if it does take several hours to re-install this game (mostly CPU-time during download and update check)...
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #9 from Chiitoo escomk3@hotmail.com --- Ah, it just so happens that, indeed, I was running into a new issue caused by 9cc92365 [1], which breaks Wine completely for me.
Before this commit, the output is similar to what it was before here.
1. https://source.winehq.org/git/wine.git/commit/9cc92365560f19c2fd2b9796f79aa7...
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #10 from Henri Verbeet hverbeet@gmail.com --- (In reply to Chiitoo from comment #8)
I'm not sure how much we should care if this is the only way the issue is triggered, even if it does take several hours to re-install this game (mostly CPU-time during download and update check)...
I think this issue is unfortunate, but ultimately not one we can do much about beyond documenting things in the AppDB.
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #11 from Chiitoo escomk3@hotmail.com --- Huh, I was thinking about this issue just yesterday, and again today. :]
Yeah, this definitely looks like something that we can live with, unless it somehow affects other things later on as well, I maybe guess.
https://bugs.winehq.org/show_bug.cgi?id=47651
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|PlayOnline Viewer: Page |PlayOnline Viewer crashes |fault on read access at |when upgrading a prefix |launch time. |created before c5577721b9 Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- Changing resolution back to INVALID, then (or I guess WONTFIX could work...?)
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #13 from Henri Verbeet hverbeet@gmail.com --- In case this is useful to anyone running into this, it looks like the application stores the depth-buffer format in %windir%\d3dx.dat. Deleting/moving that file allows the application to start again, after which d3dx.dat is recreated.
https://bugs.winehq.org/show_bug.cgi?id=47651
--- Comment #14 from Chiitoo escomk3@hotmail.com --- (In reply to Henri Verbeet from comment #13)
In case this is useful to anyone running into this, it looks like the application stores the depth-buffer format in %windir%\d3dx.dat. Deleting/moving that file allows the application to start again, after which d3dx.dat is recreated.
Oh! Very useful indeed (I still never got to tracking it down). I think I'll add a note about that in the AppDB entry.
Many thanks!
https://bugs.winehq.org/show_bug.cgi?id=47651
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=47651
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #16 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=47651
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Gijs Vermeulen gijsvrm@gmail.com --- Closing INVALID.