https://bugs.winehq.org/show_bug.cgi?id=54534
Bug ID: 54534
Summary: dbghelp:dbghelp - The test_loaded_modules()
enumeration fails on Windows 10 1607
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
dbghelp:dbghelp - The test_loaded_modules() enumeration fails on Windows 10
1607:
dbghelp.c:517: Test failed: SymLoadModuleExW failed on
C:\WINDOWS\System32\bcryptPrimitives.dll: 0
See https://test.winehq.org/data/patterns.html#dbghelp:dbghelp
This is the only Windows 10 version which fails.
A bisect confirms that this failure was introduced by the commit below:
8be5c10ff893a22330ad94ae18dfb5fa497b09fd
Author: Eric Pouech <eric.pouech(a)gmail.com>
AuthorDate: Thu Feb 16 10:48:53 2023 +0100
dbghelp/tests: Add tests for 'module' name in EnumLoadedModules() callback.
Signed-off-by: Eric Pouech <eric.pouech(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.
https://bugs.winehq.org/show_bug.cgi?id=43224
Bug ID: 43224
Summary: Freelist scan can result in O(n) time when allocating
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: ranma42(a)gmail.com
Distribution: ---
Created attachment 58517
--> https://bugs.winehq.org/attachment.cgi?id=58517
Micro-benchmark that shows the degenerate behaviour
The heap implementation in ntdll can be very inefficient for some allocation
patterns.
Specifically, it is possible that a freelist contains thousands of entries of a
given size and it is scanned while looking for a bigger entry, that will not
fit in any of those.
This is demonstrated by the attached program. It accepts a size as an argument
and will allocate 1000000 elements of that size, deallocate half of them (the
"even" ones), then allocate 1000 elements that are just one bit bigger.
For most sizes the program terminates in milliseconds, but in my environment it
takes several seconds for sizes 16, 32, 48, 64, 80, 88, 96, 112, 120, 128.
A possible workaround (that I had implemented in the past, for short-lived
applications) is to allocate from a freelist whose entries are all at least as
big as the block that is being allocated, but that can cause inefficient memory
usage.
I noticed that wine includes an implementation of a red-black tree.
Would it make sense to organise the free entries as lists in such a tree?
That should ensure O(log N) in the worst case.
If performance is a concern, it might be possible to use "direct" freelists for
small sizes (ensuring that all of the alignment-compatible sizes are covered)
and use a tree for bigger sizes.
I am willing to work on this, but I need some directions on what is the best
path forward (namely, if we should prefer the memory-inefficient but simpler
approach of just allocating from "bigger" freelists or if the tree approach is
the desired one).
The bug https://bugs.winehq.org/show_bug.cgi?id=37773 might be related.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=37146
Bug ID: 37146
Summary: Untis 2015: Crashes while starting
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: schutthuffe(a)web.de
Created attachment 49371
--> https://bugs.winehq.org/attachment.cgi?id=49371
Report generated by wine
Installing Untis 2015 seemed to work. Trying to start the program, the
following message popped up: "Im Programm untis.exe traten schwerwiegende
Fehler auf und es muss beendet werden. Wir entschuldigen uns für die
Unannehmlichkeit." The following report is attached.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54582
Bug ID: 54582
Summary: kernel32:locale - test_NLSVersion() fails on Windows
10 22H2
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
kernel32:locale - test_NLSVersion() fails on Windows 10 22H2:
locale.c:7871: Test failed: IsValidNLSVersion succeeded
See https://test.winehq.org/data/patterns.html#kernel32:locale
Apparently the point of this set of test is to verify that IsValidNLSVersion()
rejects any version different from that returned by GetNLSVersion().
But sometimes that's not the case. Indeed a similar failure happened on Windows
10 2004 back in the day, see bug 51159. In that case IsValidNLSVersion()
accepted versions 0x100 lower than the current one, presumably because that
version of Windows was keeping compatibility with older NLS versions. That one
was fixed by making bigger changes to the version.
In this case Windows 10 22H2 accepts NLS versions that are 0x100 greater than
the current one. So presumably we can just use a larger increment to get the
expected failure.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54338
Bug ID: 54338
Summary: Swift crashes due unimplemented
QueryUnbiasedInterruptTimePrecise function
Product: Wine
Version: 8.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mikrutrafal(a)protonmail.com
Distribution: ---
Swift language after installing, crashes with this message
```
wine: Call from 000000017002FA08 to unimplemented function
api-ms-win-core-realtime-l1-1-1.dll.QueryUnbiasedInterruptTimePrecise, aborting
wine: Unimplemented function
api-ms-win-core-realtime-l1-1-1.dll.QueryUnbiasedInterruptTimePrecise called at
address 000000017002FA08 (thread 0110), starting debugger...
```
Steps to reproduce
- install Swift 5.7.2 -
https://download.swift.org/swift-5.7.2-release/windows10/swift-5.7.2-RELEAS…
- execute `wine swift`
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53504
Bug ID: 53504
Summary: Sacred:unhandled exception in Wine 7.14
Product: Wine
Version: 7.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: chebanenkoigor93(a)gmail.com
Distribution: ---
Created attachment 72868
--> https://bugs.winehq.org/attachment.cgi?id=72868
screenshot
Wine 7.14 gives me exception after launching Sacred.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=24256
Summary: 3D Sexvilla 2: extremely long loading times
Product: Wine
Version: 1.2
Platform: x86
URL: http://www.3d-sexgames.com/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mailme667(a)yahoo.co.uk
Loading time makes the game unusable (version 2.093). I just watched the
loading screen for half an hour. But I know it works, because I tried starting
the game, turning the monitor off, having dinner and see the game running when
I came back a long time later.
Clean .wine tested. Other users in appdb have reported the same problem, it's
not just me.
Bug is tested to be present on wine 1.2 and 1.3.1. sysprof makes it clear ntdll
is consuming nearly all the time.
Using wine 1.2 the following is seen repeating over and over with winedebug
during loading:
002e:Call KERNEL32.GetTickCount() ret=7da7655d
002e:Ret KERNEL32.GetTickCount() retval=00032601 ret=7da7655d
002e:Call KERNEL32.GetTickCount() ret=7e7997bb
002e:Ret KERNEL32.GetTickCount() retval=00032601 ret=7e7997bb
002e:Call KERNEL32.GetTickCount() ret=7e7997bb
002e:Ret KERNEL32.GetTickCount() retval=00032607 ret=7e7997bb
002e:Call KERNEL32.GetTickCount() ret=7da76415
002e:Ret KERNEL32.GetTickCount() retval=00032607 ret=7da76415
002e:Call ntdll.RtlAcquireResourceShared(00187fa4,00000001) ret=7da76541
002e:Ret ntdll.RtlAcquireResourceShared() retval=00000001 ret=7da76541
002e:Call ntdll.RtlReleaseResource(00187fa4) ret=7da76555
002e:Ret ntdll.RtlReleaseResource() retval=00000000 ret=7da76555
I got the following from wine-dbg also using 1.2:
Wine-dbg>bt 0x0000002e
Backtrace:
=>0 0xb7705430 (0x04e0e9d8)
1 0x7e78ea4a TIME_MMSysTimeThread+0x329(arg=0x4e0ea34)
[/build/buildd/wine1.2-1.2/dlls/winmm/time.c:218] in winmm (0x04e0ea68)
2 0x7e78ea4a TIME_MMSysTimeThread+0x329(arg=0x7e770000)
[/build/buildd/wine1.2-1.2/dlls/winmm/time.c:218] in winmm (0x04e0ea78)
3 0x7bc6f8f0 call_thread_func+0xb() in ntdll (0x04e0eb48)
4 0x7bc6fac0 call_thread_entry_point+0x6f(entry=0x7e78e720, arg=0x7e770000)
[/build/buildd/wine1.2-1.2/dlls/ntdll/signal_i386.c:2473] in ntdll (0x04e0f398)
5 0x7bc780b5 start_thread+0xf4(info=0x7ff9cfb8)
[/build/buildd/wine1.2-1.2/dlls/ntdll/thread.c:399] in ntdll (0x04e0f498)
6 0xb757780e start_thread+0xbd() in libpthread.so.0 (0x00000000)
I hope I've provided enough information.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
https://bugs.winehq.org/show_bug.cgi?id=53094
Bug ID: 53094
Summary: ntdll:rtlstr test crashes on win32 arch with hi-IN
locale
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: rbernon(a)codeweavers.com
Regression SHA1: d8c973ad95ba5e8a9a51df0dd9be587950179ec3
Distribution: ---
As seen on the testbot nightly runs there for instance:
https://test.winehq.org/data/c1e793f1119de0c0ef7d4bd6d9fefbafdb5dbbe5/linux…
Locally reproducible with:
LC_ALL=hi-IN.UTF-8 LC_LANG=hi-IN.UTF-8 WINEARCH=win32 WINEPREFIX=$PWD/pfx
wine32/wine wine32/dlls/ntdll/tests/ntdll_test.exe rtlstr
Bisected to:
commit d8c973ad95ba5e8a9a51df0dd9be587950179ec3
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon May 30 22:38:28 2022 +0200
kernelbase: Reimplement CompareStringEx using the sortkey generation code.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
dlls/kernel32/tests/locale.c | 117 +++++++++-----------
dlls/kernelbase/locale.c | 247 +++++++++++++++++--------------------------
2 files changed, 147 insertions(+), 217 deletions(-)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51259
Bug ID: 51259
Summary: 6.0.1 Introduces error causing Wavelab to close when
loading presets
Product: Wine
Version: 6.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shagooserver(a)gmail.com
Distribution: ---
Update 6.0.1 (7/6/21) introduces an error whereby Wavelab 6 closes/crashes when
a preset is loaded (into the master section).
The terminal outputs:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 151 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 6199
Current serial number in output stream: 6200
--
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.
https://bugs.winehq.org/show_bug.cgi?id=49113
Bug ID: 49113
Summary: Wine heap performs badly when multiple threads are
concurrently allocating or freeing memory
Product: Wine
Version: 5.7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: rbernon(a)codeweavers.com
Distribution: ---
This can be easily reproduced with any synthetic heap benchmark, such as
https://github.com/mjansson/rpmalloc-benchmark or
https://github.com/daanx/mimalloc-bench.
Performance gets really bad as the number of concurrent thread increases.
For instance, running the rpmalloc benchmark with "<num threads> 0 0 2 20000
50000 5000 16 1000" parameter set, and 2 concurrent threads gives the following
results (wine staging is testing with the staging heap improvement patches from
https://bugs.winehq.org/show_bug.cgi?id=43224):
* win10 crt: 11977625 memory ops/CPU second, 106% overhead
* linux crt: 5675754 memory ops/CPU second, 53% overhead
* wine rpmalloc: 19700003 memory ops/CPU second, 131% overhead
* wine upstream: 248333 memory ops/CPU second, 62% overhead
* wine staging: 914004 memory ops/CPU second, 61% overhead
Increasing the number of thread makes the difference even worse for Wine.
In general this does not translate in much slowdowns, as memory allocation is
rarely done in such highly concurrent way, but in some situations the
difference is clearly noticeable, and in particular with many games during
their loading times.
--
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.