January 2020 - Wine-Bugs - list.winehq.org

[Bug 48374] Divinity: Original Sin 2 - Icons in inventory are invisible (...again!)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48374 --- Comment #7 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Erich E. Hoover from comment #6) > ... > Please try applying these two patches: > [1] https://source.winehq.org/patches/data/176267 > [2] https://source.winehq.org/patches/data/176268 These were committed today, so you should be able to just update. -- 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.

Jan. 2, 2020

[Bug 48381] Regression: Video clips shows black on Beasts & Bumpkins

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48381 --- Comment #12 from Zebediah Figura <z.figura12(a)gmail.com> --- To be perfectly honest, I have no idea what's going wrong. I can't even reproduce a difference on either of two machines (one using nouveau, the other amdgpu) between the offending patch and reverting it. When pressing "start game" I see a short clip of mist and the word "Lokyadore", followed by a clip of scrolling text over a still image, and then clicking through that brings me to an interactive game screen, and this is the case regardless of whether or not 70d842b10 is reverted. The only difference is that with 70d842b10 in effect, resolution changes take an extra couple of seconds to happen, but this unfortunately expected and there's not really anything we can do about it. I can't figure out why the commit would even cause regressions (besides by somehow triggering the window to lose focus?) unless it's the display driver's fault, and I can't find anything in the log that elucidates the matter. In comment 11 you say there are 3 videos; which one is the third one? I'm not sure I'm actually getting 3 in any case. -- 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.

Jan. 2, 2020

[Bug 48291] Detroit: Become Human crashes on launch

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48291 Andrew Wesie <awesie(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |awesie(a)gmail.com --- Comment #51 from Andrew Wesie <awesie(a)gmail.com> --- (In reply to Paul Gofman from comment #37) > (In reply to David Torok from comment #36) > > I've been thinking about ways to go about this, and thought we could rewrite > > the seccomp filter to trap only on virtual addresses outside of glibc. (see > > the attachment) > > > > What are your thoughts, would that work well for us? > > Please note the following: > > - Linux programs and libraries are doing syscalls directly whenever they > want often bypassing glibc wrappers. Some syscalls don't even have such > wrappers. Wine does a number of syscalls directly, so do a lot of native > libraries. So the address range from where you can get a native syscall is > absolutely not limited by glibc code segments. > I think filtering on the instruction pointer could work on 64-bit, because you don't need to reuse address space; 32-bit is a different matter. Wine already runs out of address space with some programs. You can load one seccomp filter per windows DLL / exec mapping and trap if the instruction pointer is within the address range. For better performance, if you can reserve a "large enough" area of memory for these mappings, you would only need one seccomp filter in the fast case. This would avoid the problem of trying to guess which Linux libraries use syscalls. On 32-bit, you might be able to get away with using VDSO to detect Linux syscalls. I know that glibc will use VDSO for syscalls if possible, not sure about other libraries we may be concerned about. > - glibc (and other libraries) can be loaded at different addresses, and you > can't ever change seccomp filters: once set, they are inherited by the child > processes and can't be removed or replaced, only new filters can be added. > Maybe there is an exception for process having admin caps (CAP_SYS_ADMIN), > but that's not something I would mess with in Wine. > Honestly, wine should not generally be using exec* system calls. I am not saying that it doesn't, just that if we think about the semantics of creating a new process on Windows, the new process should be forked from wineserver or something. Since seccomp appears to be per-thread, maybe you could create an unconstrained thread that will be used for fork and exec*. This would avoid adding more cruft to wineserver or additional IPC. -- 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.

Jan. 2, 2020

[Bug 48401] GTA IV - Framerate drop after 5 minutes of gameplay

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48401 --- Comment #8 from Dennis Mayr <dmayr.dev(a)gmail.com> --- I also ran LaunchGTAIV.exe with the following commandline argument: -memrestrict 314572800 (medium textures, to avoid memory leaks according to Rockstar support) -- 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.

Jan. 2, 2020

[Bug 48401] GTA IV - Framerate drop after 5 minutes of gameplay

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48401 Alexandr Oleynikov <sashok.olen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sashok.olen(a)gmail.com | -- 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.

Jan. 2, 2020

[Bug 48401] GTA IV - Framerate drop after 5 minutes of gameplay

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48401 --- Comment #7 from Dennis Mayr <dmayr.dev(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #6) > Hello, > > 1. Retest with recent wine-devel/wine-staging (5.0-rc*). > > 4.0.3 is wine-stable and doesn't include the latest fixes and features. > > --- quote from https://wiki.winehq.org/Bugs#When_to_report_a_bug --- > When to report a bug > (...) > · You are using the latest development version of Wine (not stable) (See > downloads for information on how to get the latest). > (...) > --- end quote --- > https://www.winehq.org/download > > 2. Try with Windows version 7 in winecfg. > Unless the application has a specific need for Win10 you should use the > default Win7 mode. > > 3. If the above doesn't fix the issue: > Attach a normal (=without WINDEBUG) terminal output). > Instructions to get a log can be found there: > https://wiki.winehq.org/FAQ#get_log > > 4. Please also state how much system RAM you have. > The issue you describes happens on Windows too (search for 'gta 4 lags after > few minutes' on any search engine). On Windows it is related to Page Caching > on disk when system RAM is exhausted. > > 5. Please also add the bug link to the AppDB entry of your version. > If you don't have/want an AppDB account, please tell the version so that I > can add the link myself. > https://appdb.winehq.org/objectManager.php?sClass=application&iId=8757 > > 6. Black screen with nouveau may be bug 38863. > Please, Let this bug focus on the lag issue only. > > Regards. Hi! I just retested. 1. I've used wine-5.0-rc3 2. Windows 7 mode worsened performance in comparison to Windows 10 mode 3. log.txt yielded nothing 4. My machine has 4Gb of RAM, no other applications are open at the time GTA IV is running 5. I'm using the Title Update 7 version of the game: https://appdb.winehq.org/objectManager.php?sClass=version&iId=22316 -- 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.

Jan. 2, 2020

[Bug 46058] iPed 7G 2019 (.NET 4.0 app) v13.0.10800 crashes with System.NotImplementedException (METAFILE_DrawPath is a stub)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=46058 --- Comment #10 from John Tamburo <johntam(a)pedfast.com> --- Has there been any progress on this bug? -- 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.

Jan. 2, 2020

[Bug 48302] Warhammer Online doesn't render without d3dx9_34

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48302 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #11 from Matteo Bruni <matteo.mystral(a)gmail.com> --- (In reply to Matteo Bruni from comment #10) > (In reply to Paul Gofman from comment #9) > > This issue is not a regression, so probably a no go during the code freeze. > > I was planning to finalize the unit test and suggest the patch upstream > > after code freeze (I guess late January or so). > > I think the patch should be okay for code freeze, it's still a bug fix with > very low risk. We do want to test (not necessarily Wine tests) which d3dx9 > versions require the flag. FWIW 3a5688a795532640bb32bd4c3e9961c6ab9f19fa > implies the behavior changed with d3dx9_37 for effect shaders. Eh, I was referring to the d3dx9 patch while you were talking about the wined3d change. Actually the wined3d one is probably also okay, we don't restrict acceptable patches to regression fixes only (especially when there are still a few weeks to go) and the change is very contained. Of course others might disagree so the patch can still end up deferred. -- 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.

Jan. 2, 2020

[Bug 48408] New: mixthread monopolizes buffer_list_lock if WaitForSingleObject returns quickly, causing livelock and game freeze

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48408 Bug ID: 48408 Summary: mixthread monopolizes buffer_list_lock if WaitForSingleObject returns quickly, causing livelock and game freeze Product: Wine Version: 5.0-rc3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dsound Assignee: wine-bugs(a)winehq.org Reporter: florian.will(a)gmail.com Distribution: --- Created attachment 66179 --> https://bugs.winehq.org/attachment.cgi?id=66179 C source for reproducing this issue, livelocks on my system The default WaitForSingleObject implementation is not fast enough to trigger this, but the bug manifests itself when starting wine-staging with WINEESYNC=1. I originally reported this at https://github.com/ValveSoftware/Proton/issues/3387 , but I am now able to reproduce this on wine-staging. The problem is in dsound though. The dsound mixthread locks the buffer_list_lock, then calls PerformMix(), then releases the lock, then waits for something to happen using WaitForSingleObject, then locks the buffer_list_lock again, in a loop. This works fine when not using esync (I guess Valve's fsync also triggers the same issue), since the default WaitForSingleObject implementation is slow enough to allow other threads to acquire the buffer_list_lock while the mixthread executes WaitForSingleObject. However, when esync is enabled AND the mixthread has a lot of work to do (because there are many secondary sound buffers), it apparently returns from WaitForSingleObject almost immediately, and very quickly re-acquires the lock after releasing it. The lock implementation does not guarantee fairness, and on my system, this results in the mixthread monopolizing the buffer_list_lock. If the main thread then wants to add a new secondary sound buffer to the list, it attempts to acquire the buffer_list_lock exclusively, but it can take a very long time to acquire the lock. This leads to a game freeze in Zusi 3 and maybe other games / applications if there are lots of sound effects at the same time. I have added a Sleep(1) in the mixthread before acquiring the lock, and it fixed the freezes (but it will obviously cause audio stuttering to kick in earlier than without the sleep). Disabling esync also fixes the freeze. I came up with a simple reproducer, C source attached. Output is like this with esync enabled: [..] Added buffer No. 283, took 0.056744 sec! Added buffer No. 284, took 0.616793 sec! Added buffer No. 285, took 16.775508 sec! Added buffer No. 286, took 11.163868 sec! Added buffer No. 287, took 26.308287 sec! Obviously on more powerful systems with better single-thread CPU performance, more buffers will be needed before it "almost-livelocks" like this. This output is from my Phenom II X4 955. (If sound starts stuttering instead of the freeze/lock, the bug did not manifest itself.) With esync disabled (or when using my patched dsound.dll with "Sleep(1)"), it never takes longer than 0.1 sec to add a buffer. -- 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.

Jan. 2, 2020

[Bug 47996] Battlefield 2 Unhandled exception

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=47996 consolelogger <consolelogger(a)rhyta.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #4 from consolelogger <consolelogger(a)rhyta.com> --- seems not to happen anymore with wine5.0rc3 -- 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.

Jan. 2, 2020