https://bugs.winehq.org/show_bug.cgi?id=53171
Bug ID: 53171
Summary: advapi32:registry - test_performance_keys() sometimes
fails due to time going backwards!
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
advapi32:registry - test_performance_keys() sometimes fails due to time going
backwards:
registry.c:3757: Test failed: key FFFFFFFF80000004: value (null): got times
132999520626290092, 132999520626290092, 132967560392269933
registry.c:3763: Test failed: key FFFFFFFF80000004: value (null): got times
132999520626290092, 132999520626290000, 132967560392269933
https://test.winehq.org/data/patterns.html#advapi32:registry
This failure is pretty rate: I only found 4 cases (~0.9%):
win2009_newtb-w1064-tsign, win21H1_newtb-w10pro64-mx-MX, 2x
win21H2_fgtb-w10pro64.
The failure lines above happened on w10pro64-mx-MX on 2022-06-17. Here are the
corresponding timestamps:
systime1 = 132999520626290092 = 2022-06-17 15:07:42.629009
file_time = 132999520626290000 = 2022-06-17 15:07:42.629000
systime2 = 132967560392269933 = 2022-05-11 15:20:39.226993
file_time is a little lower than systime1 which is normal due to its
granularity.
What is totally wrong however is that systime2 is way lower than systime1. The
interesting part is that the live snapshot was created on 2022-05-11 which
matches systime2. This scenario is confirmed it two of the other instances; the
snapshot creation time for the last case is unknown but a match with systime2
is plausible.
After restoring the VM from the live snapshot LibvirtTool sets the VM time
through TestAgent::SetTime():
https://gitlab.winehq.org/winehq/tools/-/blob/master/testbot/bin/LibvirtToo…https://gitlab.winehq.org/winehq/tools/-/blob/master/testbot/src/testagentd…
So it looks like in rare cases the system time gets reset backwards precisely
between this test's two NtQuerySystemTime() calls, which is really unlucky...
or lucky: maybe it happens in other cases causing less obvious failures.
I don't know if TestAgentd sets the time wrong, if there's something wrong with
Windows, or if this is an artifact of the QEmu clocks:
<clock offset='localtime'>
<timer name='rtc' tickpolicy='delay'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='yes'/>
<timer name='hypervclock' present='yes'/>
</clock>
--
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=52492
Bug ID: 52492
Summary: stack overflow from GdipFlattenPath
Product: Wine
Version: 7.1
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: rjfeuerbach(a)gmail.com
Created attachment 71787
--> https://bugs.winehq.org/attachment.cgi?id=71787
test patch to replicate the curves and stack overflow
I have a third party application, unfortunately not available for download,
that is generating a virtual stack overflow error. Using +replay and
eventually +gdiplus messages, the cause was narrowed down to be due to calls to
GdipFlattenPath.
Attached is a patch to gdiplus/test/graphicspath.c to include the precise
curves that cause the stack overflow.
I believe the problem is due to the comparison of REALs with == in the
flatten_bezier helper function.
--
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=54720
Bug ID: 54720
Summary: Spider-Man: Shattered Dimensions - dialogue audio
doesn't play
Product: Wine
Version: 8.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: xaudio2
Assignee: wine-bugs(a)winehq.org
Reporter: tinozzo123(a)tutanota.com
Distribution: ---
Created attachment 74226
--> https://bugs.winehq.org/attachment.cgi?id=74226
Logs taken with a clean 32 bit prefix with 32 bit Wine devel 8.4,
WINEDEBUG=+xactengine,+xaudio2,+x3daudio.
In Spider-Man: Shattered Dimensions, the audio that is supposed to be played by
the characters during in-game dialogues doesn't play.
All the other kinds of audio work.
A workaround to this is by installing xact with winetricks.
--
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=44816
Bug ID: 44816
Summary: Cygwin/MSYS2 `script -e` exit status forwarding
randomly returns zero for non zero child process
Product: Wine
Version: 3.4
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
to track
https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-Deal…
Mentioned here:
https://wine-staging.com/news/2015-08-23-release-1.7.50.html
--- quote ---
Do not allow to deallocate thread stack for current thread (MSYS2, Wine Staging
Bug #241)
--- quote ---
After some archaeology I found the Cygwin mailing list discussion here:
https://cygwin.com/ml/cygwin/2015-09/msg00114.html
--- quote ---
> Ah, ok. What OS does Wine emulate here? Have a look at
> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/cygt…
>
> The terminate_thread_frees_stack flag is set to false for XP/2003 and to
> true for any newer OS. I guess this is a double-free because Wine's
> TerminateThread already freed the stack and Cygwin got the info it's
> supposedly running under XP/2003, so it tries to workaround the fact
> that TerminateThread on these systems didn't free the stack by themselves.
>
Wine emulates Windows XP here, I double checked Wine source code and I
can confirm Wine doesn't free the stack:
NtTerminateThread() -> abort_thread() -> terminate_thread()
https://github.com/wine-compholio/wine-patched/blob/8b3a785e97a7e28ff58731b…
Cygwin reports wincap as wincap_xpsp2 which is also correct here.
> we need to know what address ret=61005767 is refering to. addr2line would help.
As you point out, ret=61005767 is the call to VirtualFree() inside
cygthread::terminate_thread ()
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/cygt…
After combine the information we have so far, I think the problem is
clear now. It's not Cygwin's fault, it's Wine's fault. Wine's
WaitForSingleObject() needs to wait long enough after the
TerminateThread() call, so the target thread has enough time to finish
the system cleanup and return correct exit_code before Cygwin call
VirtualFree to free the stack. But in our current implementation
Wine's WaitForSingleObject returns too early, it shouldn't return
before the system thread cleanup done, as a result there is a race
here. We are thinking of a solution in Wine. Thanks again for the
great help!
--- quote ---
$ wine --version
wine-3.4
Regards
--
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=30655
Bug #: 30655
Summary: GRID2: Low (1 - 3) FPS during race, but not in in-game
menus.
Product: Wine
Version: 1.5.2
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: linards.liepins(a)gmail.com
Classification: Unclassified
Created attachment 40128
--> http://bugs.winehq.org/attachment.cgi?id=40128
in-game benchmark test #!
Game itself installed with latest winetricks.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=28603
Bug #: 28603
Summary: Winedbg sometimes receives invalid parameters
Product: Wine
Version: 1.3.29
Platform: x86
URL: http://www.winehq.org/pipermail/wine-patches/2011-Sept
ember/106508.html
OS/Version: Linux
Status: NEW
Keywords: download, source, testcase
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
CC: julliard(a)winehq.org
Classification: Unclassified
Created attachment 36753
--> http://bugs.winehq.org/attachment.cgi?id=36753
relay,seh,tid,dbghelp,winedbg
I sent a patch to eliminate this dialog:
http://www.winehq.org/pipermail/wine-patches/2011-September/106508.html
but Alexandre said this should never happen. I see it occasionally on various
systems, but since I wrote the patch, haven't found a very reliable testcase.
I've found a reliable testcase with make test on Alpine Linux (which uses
uclibc).
It may not be the best testcase, since it's not using glibc (and also use PaX),
but AJ asked for a log, so here we go :).
relay,seh,tid,dbghelp,winedbg attached
the testcase used was oleaut32/tmarshal
wine-1.3.29-217-g5432611
--
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=54413
Bug ID: 54413
Summary: ws2_32:sock - DuplicateHandle(socket) sometimes look
like a socket in test_WSAGetOverlappedResult() on
Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ws2_32:sock - DuplicateHandle(socket) sometimes look like a socket in
test_WSAGetOverlappedResult() on Windows:
sock.c:12512: Test failed: got 1.
sock.c:12513: Test failed: got 0.
See https://test.winehq.org/data/patterns.html#ws2_32:sock
This failure is pretty rare, there are only 4 known instances:
* 2022-09-27 on w1064 64 bit (21h2)
* 2022-11-15 on w10pro64-hi-u8 64 bit (21h1)
* 2023-01-25 on w11pro64 64 bit (21h2)
* 2023-01-25 on w1064v2009 64 bit
The test creates a socket, treats it as a handle and duplicates it, then checks
whether the duplicate handle behaves like a socket which it normally does not,
causing WSAGetOverlappedResult() to fail (return 0) and WSAGetLastError() to be
set to WSAENOTSOCK.
But in these four cases WSAGetOverlappedResult() succeeded which would indicate
the duplicate handle looked like a socket?
--
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=44546
Bug ID: 44546
Summary: The Settlers II: 10th Anniversary runs very slow when
CSMT enabled
Product: Wine
Version: 3.2
Hardware: x86
URL: https://www.fileplanet.com/165168/160000/fileinfo/The-
Settlers-II:-10th-Anniversary-Demo-v9801
OS: Linux
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
Distribution: ---
The game is running painfully slow in Wine 3.2. Can be observed while it is
playing the opening video, in the menus and during gameplay too. Loading times
are also incredibly long when csmt is enabled.
Disabling csmt makes the game run smoothly. There is nothing suspicious in the
terminal.
Can be reproduced with the demo version. I have native d3dcompiler_43 and
d3dx9_29 installed.
settlers2_demo2_multilang.exe (318M)
md5sum: c738916e0f5f4c9b780898f66e50941f
Wine 3.2
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 730/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 390.25
--
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=55152
Bug ID: 55152
Summary: Crash in Notepad++ processing a WM_DRAWITEM message
Product: Wine
Version: 8.11
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: win32u
Assignee: wine-bugs(a)winehq.org
Reporter: julliard(a)winehq.org
Distribution: ---
Running the 32-bit Notepad++ 8.5.4 in new wow64 mode crashes on startup when
processing a WM_DRAWITEM message. The exception is swallowed by win32u so it
still works, but we get a message:
0024:err:seh:KiUserCallbackDispatcher ignoring exception
The root cause is that because Notepad++ added a WH_CALLWNDPROC hook, in win32u
process_message(), instead of returning to SendMessageW and have it call the
winproc, we call it ourselves through KeUserModeCallback. But at that point the
message has been converted to 64-bit so we pass a (truncated) 64-bit lparam to
the 32-bit winproc.
The crash was revealed by a82238fad52761114ab2488d422fad3f70dbb854, which moves
the 64-bit stack to high memory. Previously the lparam pointer would fit in
32-bit which avoided the crash, but it would still point to a 64-bit
DRAWITEMSTRUCT.
--
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=51443
Bug ID: 51443
Summary: Test fails in remove_dir_all crate when creating file
Product: Wine
Version: 6.12
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: ---
Hi,
Steps to reproduce on clear wine-devel 6.12
```
wget https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi
msiexec /i rust-1.53.0-x86_64-pc-windows-gnu.msi
git clone https://github.com/XAMPPRocky/remove_dir_all.git
cd remove_dir_all
git checkout 9b164cecdb4a0590af68be8b22f9c747402237e3
wine cargo test
```
should print this
```
running 4 tests
test removes_read_only ... FAILED
test removes_empty ... ok
test removes_files ... ok
test removes_dirs ... ok
failures:
---- removes_read_only stdout ----
thread 'removes_read_only' panicked at 'called `Result::unwrap()` on an `Err`
value: Os { code: 5, kind: PermissionDenied, message: "Access denied." }',
tests\windows.rs:68:49
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
removes_read_only
test result: FAILED. 3 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out;
finished in 0.01s
error: test failed, to rerun pass '--test windows'
```
I tested it and this works fine in Windows Server 2019
Source code of failed test -
https://github.com/XAMPPRocky/remove_dir_all/blob/9b164cecdb4a0590af68be8b2…
```
fn removes_read_only() {
env_logger::init();
for i in 0..5 {
let path = format!("./readonly/{}/subdir", i);
fs::create_dir_all(&path).unwrap();
let file_path = format!("{}/file.txt", path);
{
let file = File::create(&file_path).unwrap();
```
--
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.