May 2023 - Wine-Bugs - list.winehq.org

[Bug 54976] Mono/.Net assemblies fail to start: Application could not be started, or no application associated with the specified file.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54976 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |f6f38e24906ebbe1d22d32c6233 | |8be4354a55bd5 Summary|Since |Mono/.Net assemblies fail |4356fe0d830759a4bc194f21f3c |to start: Application could |8fc3a36ca2ca0 program fails |not be started, or no |to start: Application could |application associated with |not be started, or no |the specified file. |application associated with | |the specified file. | |(regression) | --- Comment #2 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- This is fixed by f6f38e24906ebbe1d22d32c62338be4354a55bd5 Thanks Alexandre -- 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.

May 26, 2023

[Bug 54978] vbscript fails to compile Sub when End Sub on same line

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54978 --- Comment #1 from francisdb <francisdb(a)gmail.com> --- as a workaround Sub Sw35_UnHit():Controller.Switch(35)=0: End Sub would work as well -- 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.

May 26, 2023

[Bug 54979] Futexes which protect memory allocation congest, causing 100x performance degradation

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54979 --- Comment #3 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #1) > However, we can probably avoid RtlWaitOnAddress for critical sections. This is harder than I thought. I thought it would be relatively easy to implement a lock-free wait queue on the stacks of the waiting threads, but after thinking it through I don't think it's actually possible at all. In theory we could try supplying hints as to which thread to wake (say, with a bounded ring buffer). The problem with this is that we only have a pointer's worth of space to work with, and we can't allocate more because we underly the heap implementation. (In reply to John Nagle from comment #2) > There are three nested locks here, two futexes and a hard spinlock. The one > that looks most suspicious is the middle one at wait_semaphore. That loop > repeatedly calls RtlWaitOnAddress, which is probably why control is usually > in the innermost spinlock on a debugger break. If wait_semaphore didn't do > that, the problem might go away. I don't think this is suspicious. We use RtlWakeAddressSingle(), and win32 futexes are fair, so in theory a given waiting thread should only actually be woken once. At worst I think it can have one stale buffered wakeup from a previous alert. -- 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.

May 25, 2023

[Bug 54974] armv7 ELF builds crashing since "ntdll: Support the machine extended parameter in NtMapViewOfSectionEx()."

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54974 Martin Storsjö <martin(a)martin.st> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bce5a7910e4b3cf38a52a6f42e4 | |c81f720f364e9 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Storsjö <martin(a)martin.st> --- Fixed by bce5a7910e4b3cf38a52a6f42e4c81f720f364e9. -- 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.

May 25, 2023

[Bug 50955] .netCore app can't bind to port shortly after another .netCore program binding to the same port was terminated

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=50955 Bernhard Kölbl <besentv(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Bernhard Kölbl <besentv(a)gmail.com> --- This was fixed upstream a while ago. -- 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.

May 25, 2023

[Bug 54533] mfmediaengine:mfmediaengine - On Windows test_TransferVideoFrames() fails on AMD GPUs

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54533 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- The goal should be to understand why it's different on AMD, not simply skipping. -- 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.

May 25, 2023

[Bug 54533] mfmediaengine:mfmediaengine - On Windows test_TransferVideoFrames() fails on AMD GPUs

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54533 Bernhard Kölbl <besentv(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |besentv(a)gmail.com --- Comment #1 from Bernhard Kölbl <besentv(a)gmail.com> --- The problem with this test is, that it seems to be suffering from an AMD driver bug. When you look at the generated image it's really clear that it's garbage output. The only real way to fix this test would be to check for GPU vendor and skip the tests accordingly, not sure if that's a good solution though? -- 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.

May 25, 2023

[Bug 54979] Futexes which protect memory allocation congest, causing 100x performance degradation

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54979 --- Comment #2 from John Nagle <nagle(a)animats.com> --- I don't see an easy way to eliminate that innermost spinlock, either. It's not a long lock. The slowest thing inside is searching a linear list of waiting threads, which ought to take maybe a microsecond. So it may be that the outer loops are asking for that lock too often. There are three nested locks here, two futexes and a hard spinlock. The one that looks most suspicious is the middle one at wait_semaphore. That loop repeatedly calls RtlWaitOnAddress, which is probably why control is usually in the innermost spinlock on a debugger break. If wait_semaphore didn't do that, the problem might go away. The outermost lock has if (crit->LockCount > 0) break; /* more than one waiter, don't bother spinning */ so it's protected against this kind of problem. If that lock starts to build up a backlog, the thread blocks rather than spinning. But wait_semaphore doesn't have similar protection. Thanks for looking at this. -- 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.

May 25, 2023

[Bug 54979] Futexes which protect memory allocation congest, causing 100x performance degradation

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54979 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #1 from Zeb Figura <z.figura12(a)gmail.com> --- I haven't been able to find a way to avoid the spinlock for RtlWaitOnAddress. That primitive needs to be fair *and* support timeouts *and* as fast as possible, and I haven't been able to find a faster way than user-space spinlocks. However, we can probably avoid RtlWaitOnAddress for critical sections. -- 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.

May 25, 2023

[Bug 54979] New: Futexes which protect memory allocation congest, causing 100x performance degradation

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54979 Bug ID: 54979 Summary: Futexes which protect memory allocation congest, causing 100x performance degradation Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: nagle(a)animats.com Distribution: --- Created attachment 74518 --> https://bugs.winehq.org/attachment.cgi?id=74518 Debugger output with multiple threads stuck in spinlocks. SUMMARY Under the wrong circumstances, a program doing many memory allocations from multiple threads can experience more than 100x performance degradation. I'm seeing this in my own Rust program, which has 16 sometimes-compute-bound threads on a 12 CPU machine. This works fine on Microsoft Windows and when compiled for Linux. Under Wine, it can be over 100x slower. Multiple threads are banging on a spinlock at _InterlockedCompareExchange [Z:\usr\src\packages\BUILD\include\winnt.h:6630] in ntdll spin_lock [Z:\usr\src\packages\BUILD\dlls\ntdll\sync.c:937] in ntdll This is the spin lock around the queue for pausing threads. DISCUSSION This looks like futex congestion. That's a known kind of problem, but doesn't seem to have been seen in Wine before. It may be that some programs just run really slow under Wine, and nobody knows why. The code in NTDLL is clearly intended to handle the fast case without doing an OS-level lock. Under light load, that's O(1). But under heavy load, with multiple threads pounding on spinlocks, each spinlock waits longer, and there are multiple threads, so it becomes O(N^2). Which means huge slowdowns. See discussion at https://forum.winehq.org/viewtopic.php?t=37688 which has snippets of the code that's causing the problem. I can copy all that info over here if necessary. Let me know. -- 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.

May 25, 2023