https://bugs.winehq.org/show_bug.cgi?id=54546
Bug ID: 54546
Summary: ws2_32:sock - test_write_watch() gets unexpected write
counts on Windows 11
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 - test_write_watch() gets unexpected write counts on Windows 11:
sock.c:7670: Test failed: wrong count 0
sock.c:7701: Test failed: wrong count 0
sock.c:7735: Test failed: wrong count 0
sock.c:7735: Test failed: wrong count 0
sock.c:7735: Test failed: wrong count 0
sock.c:7735: Test failed: wrong count 0
See https://test.winehq.org/data/patterns.html#ws2_32:sock
--
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=52889
Bug ID: 52889
Summary: Freelancer with Crossfire mod crashes on startup
Product: Wine
Version: 6.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: poweroverwhelming982(a)gmail.com
CC: jacek(a)codeweavers.com
Regression SHA1: 6857cb56957d691bee76cfe28ef88714cca00f29
Distribution: Ubuntu
Created attachment 72282
--> https://bugs.winehq.org/attachment.cgi?id=72282
Wine log at commit 6857cb56957d691bee76cfe28ef88714cca00f29
Since wine-6.19, Freelancer with Crossfire 2.0 mod crashes immediately on
startup (as soon as the mod window is shown). Bisecting points to this commit:
> commit 6857cb56957d691bee76cfe28ef88714cca00f29
> Author: Jacek Caban <jacek(a)codeweavers.com>
> Date: Wed Sep 29 14:09:21 2021 +0200
>
> gdi32: Move ntgdi functions to Unix library.
I've attached the relevant logs, let me know if there's anything else I can do.
Additional info:
OS: Ubuntu Focal 20.04.3 LTS
Kernel: 5.13.0-30-generic x86_64
Wine Prefix: 32 bit, clean
GPU: NVIDIA Corporation GF108 [GeForce GT 730] (rev a1)
Graphics Driver: Proprietary NVIDIA ver. 390.144
--
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=52474
Bug ID: 52474
Summary: ws2_32:sock fails intermittently - 'Test failed:
expected timeout'
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
Distribution: ---
The test_connect_events() function contains the following checks, where the
check (2) fails intermittently:
1. check_events(ctx, FD_CONNECT, FD_WRITE, 200);
2. check_events(ctx, 0, 0, 0);
A hypothesis for the cause of the test failure is that the
WSAEnumNetworkEvents() call inside the check (1) races with the server setting
the event.
Note that WSAEnumNetworkEvents performs the following steps:
a. It calls ResetEvent on the given event.
b. It issues IOCTL_AFD_GET_EVENTS command on the socket to retrieve the events
so far.
It's possible that the event may be set by the server between (a) and (b),
which lingers until the next call to WSAEnumNetworkEvents(). This explains why
the event wait in check (2) is satisfied immediately but subsequent tests
report no events.
--
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=34678
Bug #: 34678
Summary: Not all serial port work in wine
Product: Wine
Version: 1.6
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: rewineland(a)gmail.com
Classification: Unclassified
I have wine 1.6 install on Ubuntu 12.04 with kernel 3.8.0-31-generial. I have 2
serial ports on board and an add-on card with 8 more.I can get the the on board
and 7 of the add-on to work as 1 though 9 comports but com10 I can not get any
data though. the port is listed as ttyCTI7, when I connect to that I have data
going back and forth. It just wont go into the windows program. Any ideas on
what to do. I need to have all 10 ports.
--
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=55283
Bug ID: 55283
Summary: amstream:amstream systematically crashes and times out
on gitlab-debian-32
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
amstream:amstream systematically crashes and times out on gitlab-debian-32:
Unhandled exception: assertion failed in wow64 32-bit code (0xf7f19559).
Backtrace:
=>0 0xf7f9a559 __kernel_vsyscall+0x9() in [vdso].so (0xf7f34ff4)
1 0xf7da21d7 in libc.so.6 (+0x8a1d7) (0xf7f34ff4)
2 0xf7d510d1 in libc.so.6 (+0x390d1) (0xf7f34ff4)
3 0xf7d3a26a in libc.so.6 (+0x2226a) (0xf7f34ff4)
4 0x71a4de79 in libllvm-15.so.1 (+0x875e79) (0x0022e910)
5 0x00000040 (0x00000040)
0xf7f9a559 __kernel_vsyscall+0x9 in [vdso].so: pop %ebp
See https://test.winehq.org/data/patterns.html#amstream:amstream
The failures started on 2023-07-10 which corresponds to the GitLab CI switch to
Debian 12.
What makes this very bad is that the failure is systematic so every single
merge request has been getting a GitLab CI error since then.
So it is pretty urgent to either:
1. Fix the test if something is wrong with it.
2. Fix the gitlab-debian-32 test environment if it is wrong.
3. Skip amstream:amstream if neither of the above is doable in a reasonable
timeframe.
--
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=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=55422
Bug ID: 55422
Summary: mfmediaengine:mfmediaengine - test_GetDuration() fails
in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mfplat
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
mfmediaengine:mfmediaengine - test_GetDuration() fails in Wine:
mfmediaengine.c:1961: Test failed: Unexpected res 0x102.
See https://test.winehq.org/data/patterns.html#mfmediaengine:mfmediaengine
This failure started with the commit that introduced the tests:
commit 613d7b099986828212299a8e98179f22c86b80ab
Author: Zhiyi Zhang <zzhang(a)codeweavers.com>
Date: Fri Aug 4 17:35:04 2023 +0800
mfmediaengine/tests: Test IMFMediaEngine::GetDuration().
--
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.