https://bugs.winehq.org/show_bug.cgi?id=45218
Bug ID: 45218 Summary: Fallout 4 Script Extender fails to allocate trampoline buffers Product: Wine Version: 3.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: buggy@ifel.se Distribution: ---
Created attachment 61445 --> https://bugs.winehq.org/attachment.cgi?id=61445 f4se log
f4se will abort initialization and launch Fallout4 without modification when launching with unpatched wine. It looks for 64K of unreserved memory before the addresses of Fallout4.exe and whichever f4se dll is being loaded for trampoline buffers.
I see two issues here. The first is that get_free_mem_state_callback is returning that a block before the exe base overlaps the exe area (ie if exe base address is 0x14000000000 it will reject a 64K block starting at 0x13FC0000000 as overlapping).
The other issue is that when the f4se dll is being loaded it's being loaded at a lower address. The code that looks for trampoline buffer space aborts when it gets to a lowest acceptable address which is the module address minus 0x78000000. For low addresses this wraps back around to a high address. Switching to loading dlls from top down stops this from happening but I doubt that's a good approach.
With the two patches I'm about to attach f4se completes initialization and everything seems to run fine.
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #1 from buggy@ifel.se --- Created attachment 61446 --> https://bugs.winehq.org/attachment.cgi?id=61446 get_free_mem_state_callback patch
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #2 from buggy@ifel.se --- Created attachment 61447 --> https://bugs.winehq.org/attachment.cgi?id=61447 map_image top down dll loading patch
https://bugs.winehq.org/show_bug.cgi?id=45218
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=45218
Jarrard Lo overlord.jarrard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |overlord.jarrard@gmail.com
--- Comment #3 from Jarrard Lo overlord.jarrard@gmail.com --- Could we get this f4se and skyrimse script extender fixes applied to wine?
It's been 21 days!
https://bugs.winehq.org/show_bug.cgi?id=45218
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Jarrard Lo from comment #3)
Could we get this f4se and skyrimse script extender fixes applied to wine?
It's been 21 days!
Thanks for the patches. Please note that patches aren't picked up from bugzilla; but rather should be submitted to wine-devel@winehq.org for consideration. See https://wiki.winehq.org/Submitting_Patches for more information.
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #5 from Jarrard Lo overlord.jarrard@gmail.com --- Sorry looks like a too hard box kind of thing, sign off by line, what the..
I can now see why so many fixes just don't ever see their way to wine.
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #6 from Austin English austinenglish@gmail.com --- (In reply to Jarrard Lo from comment #5)
Sorry looks like a too hard box kind of thing, sign off by line, what the..
I can now see why so many fixes just don't ever see their way to wine.
They don't appear to be your patches, so not sure why you're complaining about the patch process being hard..
In any case, it's a common requirement in many OSS projects, showing agreement with the project's requirements and responsibility for the patch.
You can always apply patches locally (or fork Wine if you think you can do a better job of maintaining the project).
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #7 from Matteo Bruni matteo.mystral@gmail.com --- Also, as the patch author mentioned:
Switching to loading dlls from top down stops this from happening but I doubt that's a good approach.
which is what the second patch does. So that issue probably needs some alternative fix.
The first patch seems correct to me though and could be submitted for inclusion IMHO (assuming it doesn't break the tests).
https://bugs.winehq.org/show_bug.cgi?id=45218
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=45218
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shadow@umbrox.de
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #8 from Christian Widmer CWidmer@umbrox.de --- If I understand it correctly, the second issue is not actually a bug in wine but a bug in the application itself. Would it not be best to notify the SKSE developers that their application only works by chance on windows and should therefore be fixed?
Additionally, bug 44893 seems to describe the same issue so one report should probably be marked as duplicate.
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #9 from Jarrard Lo overlord.jarrard@gmail.com --- Yes SKSE64 is same issue as F4SE, their basically the same method.
Also isn't Wine all about developing work arounds to get windows software functioning on Linux?
I think the author of the 64 bit script extenders will probably not see the light of day. I'll try and contact them sometime non the less.
At least the patches still work. Now if we could only get MO2 USVFS fully working.
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Jarrard Lo from comment #9)
Also isn't Wine all about developing work arounds to get windows software functioning on Linux?
No, not really. The goal of Wine is to emulate Windows, or more accurately to emulate the way Windows is supposed to work. We try to avoid introducing workarounds for compatibility. In this case, if the bug can be fixed on the application side, it'd be much better to do that.
https://bugs.winehq.org/show_bug.cgi?id=45218
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net URL| |http://skse.silverlock.org/ Keywords| |download, obfuscation, | |patch
https://bugs.winehq.org/show_bug.cgi?id=45218
cetedus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cetedus@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45218
bugzilla@biechl.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@biechl.net
--- Comment #11 from bugzilla@biechl.net --- Thing is, in windows the injector does work. Memory allocation seems to be handled differently in windows, so Wine does something different here. That the application does not work is a result of that.
I understand that inverting the memory allocation may not be a proper overall solution, but maybe there is a better approach that, in the end, is also more closer to "the way Windows is supposed to work"? :)
Here is what one of the developers of the said binary says about the problem, and why it can't be worked around, maybe that helps:
Since branch instructions have a range that is smaller than the address space on 64-bit operating systems, we need to allocate a buffer that is adjacent to the game's code, called a "branch trampoline". Without that, the game's code and our DLL's code may be located too far away in memory to branch directly to each other. Either WINE's loader is not supporting ASLR and loads executables at a very low address all of the time, or the functions for querying the state of memory are not implemented correctly.
https://bugs.winehq.org/show_bug.cgi?id=45218
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45218
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
--- Comment #12 from Andrew Eikum aeikum@codeweavers.com --- (In reply to buggy from comment #1)
Created attachment 61446 [details] get_free_mem_state_callback patch
This patch seems fine. Are you interested in sending it upstream, or would you like someone else to take it over?
https://bugs.winehq.org/show_bug.cgi?id=45218
--- Comment #13 from Andrew Eikum aeikum@codeweavers.com --- (In reply to buggy from comment #1)
Created attachment 61446 [details] get_free_mem_state_callback patch
This patch was merged yesterday and will be included in Wine 4.5.
The top-down mapping patch remains outstanding.
commit 12be24af8cab0e5f78795b164ec8847bafc30852 Author: Andrew Eikum aeikum@codeweavers.com Date: Wed Mar 27 11:33:25 2019 -0500
ntdll: Fix memory region check in NtQueryVirtualMemory.
Patch by buggy@ifel.se.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45218 Signed-off-by: Andrew Eikum aeikum@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=45218
buggy@ifel.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #14 from buggy@ifel.se --- Sorry, didn't mean to stall this long, been busy and never noticed these messages. Thank you for taking care of that patch. As for the other one, f4se changed their code so that it isn't necessary in newer versions. I've just built vanilla wine without it and tested with latest fo4/f4se and f4se initialized just fine, so I think this can be considered fixed now.
https://bugs.winehq.org/show_bug.cgi?id=45218
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |12be24af8cab0e5f78795b164ec | |8847bafc30852
https://bugs.winehq.org/show_bug.cgi?id=45218
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.11.
https://bugs.winehq.org/show_bug.cgi?id=45218
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=45218
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #16 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.3.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla