http://bugs.winehq.org/show_bug.cgi?id=36564
Bug ID: 36564
Summary: 'Candytron' demo: certain objects are black with GLSL
enabled
Product: Wine
Version: 1.6-rc1
Hardware: x86
URL: http://www.pouet.net/prod.php?which=9424
OS: Linux
Status: NEW
Keywords: download, regression
Severity: trivial
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: hverbeet(a)gmail.com
Regression SHA1: 2014141a253a791fc9c79aae3c8ef3c35b73e658
Created attachment 48657
--> http://bugs.winehq.org/attachment.cgi?id=48657
screenshot (comparison)
Some of the rectangles that appear in the demo nearly at 00:30 and at 01:10 are
black. They should appear as glowing green rectangles as can be seen in the
attached screenshot.
Terminal output doesn't reveal anything interesting.
Disabling GLSL is a workaround.
This is a regression from Wine 1.6-rc1:
2014141a253a791fc9c79aae3c8ef3c35b73e658 is the first bad commit
commit 2014141a253a791fc9c79aae3c8ef3c35b73e658
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Wed May 29 09:45:35 2013 +0200
wined3d: Add support for GLSL based fixed function vertex shaders.
:040000 040000 d1b4b75f643d4851d4f51454aa47740261f7857f
c46794f61b1952b1e78746272d838574c0948010 M dlls
Fedora 20
Nvidia 250 gfx card / Nvidia binary drivers 337.19
wine-1.7.19-70-gd6a59f7
--
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=55367
Bug ID: 55367
Summary: Trying to run WatchFaceStudio with wine 8.0 and Ubuntu
23 (lunar)
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tda.bkp(a)gmail.com
Distribution: ---
Created attachment 74949
--> https://bugs.winehq.org/attachment.cgi?id=74949
WatchFaceStudio.exe crash trace
Installed WatchFaceStudio successfully, but won't run. Trace 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=54831
Bug ID: 54831
Summary: GStreamer gst_init_check() crashes when called from
winegstreamer on recent macOS
Product: Wine
Version: 8.5
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: loader
Assignee: wine-bugs(a)winehq.org
Reporter: bshanks(a)codeweavers.com
On macOS Ventura (and I suspect Monterey), gst_init_check() crashes (trying to
jump to 0x0) when called by winegstreamer. This is caused by the macOS
preloader, here's how:
* gst_init_check() calls init_static_plugins()
<https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.22/subprojects/…>,
which through some GModule abstractions does a dlopen(NULL) and dlsym() for a
symbol that doesn't exist. dlsym() returns NULL, but GModule also calls
dlerror() which returns NULL (signaling no error).
* init_static_plugins() therefore thinks that the dlsym() was successful,
doesn't do a NULL pointer check, and jumps to the NULL pointer.
The issue here is dlerror() returning NULL despite there being an error to
report. Looking at the macOS dyld source code
(<https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/dyld/DyldA…>),
dlerror() always returns NULL if libSystem was not initialized in the process.
And sure enough, when running vmmap on a Wine process, the message "Process
exists but has not fully started -- dyld has initialized but libSystem has not"
is printed.
After more searching in dyld, it turns out that dyld initializes libSystem for
binaries targeting 10.5 and newer. The Wine preloader targets 10.7 (since
that's the newest target that will generate an LC_UNIXTHREAD binary, critical
to how the preloader works). But dyld determines the target OS based on where
the program vars (argc, argv, environ, etc) are stored, and a 10.6/10.7 binary
should contain a __program_vars section for those. The preloader is missing
that, and so (I believe) it falls down to being considered a 10.4 binary. A
10.4 binary should init libSystem in its own _start, but the preloader also
doesn't do this, and libSystem stays uninitialized.
(See
<https://github.com/apple-oss-distributions/dyld/blob/dyld-1042.1/common/Mac…>
for where this is determined)
I see several possible solutions:
* The most obvious one: add a __program_vars section to the preloader, to make
it a correct 10.7 binary. In fact, the code can basically be copied out of
Apple's C startup code
(<https://github.com/apple-opensource/Csu/blob/88/crt.c#L47>). This does work,
and libSystem gets initialized. However, libSystem is initialized before any
preloader code runs, and malloc zones are already in the middle of areas we
want to reserve. That's bad; by itself this approach won't work, but it might
if we also:
- add linker zerofill sections to block off the entire low 4GB. This is
desirable to reserve as much address space as possible for 32-bit EXEs in wow64
mode.
- and if zerofill sections are also added to reserve the area where 64-bit
EXEs generally load (0x14000000), it might even be possible to stop using the
preloader altogether on 64-bit.
* Alternately, go the other way, and lean in to being a 10.4 binary. In that
case, _start in the preloader needs to call back into dyld to initialize things
(like this: <https://github.com/apple-opensource/Csu/blob/88/crt.c#L219>). We
could do this after reserving our areas.
I'm leery of this approach, mainly because x86_64/10.4 was not a popular target
(GUI apps were not supported, they could only link against libSystem). If
possible, I'd rather not target such an obscure combination. The preloader has
been a source of problems with new OS versions, and I'd like to decrease the
amount of black magic it's doing, not increase it.
(Running 10.4 x86_64 binaries on modern macOS is still supported though, and
Xcode can even still build them.)
I'd like to make the __program_vars+zerofill approach work if possible.
--
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=54748
Bug ID: 54748
Summary: Greenshot GDI+ status: PropertyNotFound
Product: Wine
Version: 8.3
Hardware: x86-64
URL: https://objects.githubusercontent.com/github-productio
n-release-asset-2e65be/36756917/23e6800e-7d29-11e7-8ac
5-aa92e5646973?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-
Credential=AKIAIWNJYAX4CSVEH53A%2F20230328%2Fus-east-1
%2Fs3%2Faws4_request&X-Amz-Date=20230328T165105Z&X-Amz
-Expires=300&X-Amz-Signature=311e88c8da4b8ba0ff5ac6008
cf054338cd6e18afcf64471443530ddae088db0&X-Amz-SignedHe
aders=host&actor_id=0&key_id=0&repo_id=36756917&respon
se-content-disposition=attachment%3B%20filename%3DGree
nshot-NO-INSTALLER-1.2.10.6-RELEASE.zip&response-conte
nt-type=application%2Foctet-stream
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: lukasz.wojnilowicz(a)gmail.com
Distribution: ---
Steps to reproduce:
1) unpack Greenshot-NO-INSTALLER-1.2.10.6-RELEASE.zip
2) wine Greenshot.exe
3) RMB on Greenshot icon in the system tray
4) LMB on "Capture region"
5) Draw a rectangel on your screen
Behavior:
Error window with contents as below.
Expected behavior:
No error window.
Error window contents:
Software version: 1.2.10.6-RELEASE-c2414cf0149a1475ea00520effc01b40087c225c (32
bit)
.NET runtime version: 4.0.30319.42000+
Time: 2023-03-28 18:59:01 +02:00
OS: unknown (x32) 10.0 build 2600 revision 30000
GDI object count: 0
User object count: 0
Exception: System.Exception
Message: Unknown Error [GDI+ status: PropertyNotFound]
Stack:
at System.Drawing.GDIPlus.CheckStatus (System.Drawing.Status status)
[0x0022b] in <fc2ea6474c6d4315858618f13de6e72a>:0
at System.Drawing.Image.get_PropertyItems () [0x00017] in
<fc2ea6474c6d4315858618f13de6e72a>:0
at (wrapper remoting-invoke-with-check)
System.Drawing.Image.get_PropertyItems()
at GreenshotPlugin.Core.ImageHelper.CloneArea (System.Drawing.Image
sourceImage, System.Drawing.Rectangle sourceRect,
System.Drawing.Imaging.PixelFormat targetFormat) [0x00172] in
<68959698d73243a09b84293d02c00b84>:0
at GreenshotPlugin.Core.ImageHelper.Crop (System.Drawing.Image& image,
System.Drawing.Rectangle& cropRectangle) [0x00046] in
<68959698d73243a09b84293d02c00b84>:0
at GreenshotPlugin.Core.Capture.Crop (System.Drawing.Rectangle cropRectangle)
[0x0001a] in <68959698d73243a09b84293d02c00b84>:0
at Greenshot.Helpers.CaptureHelper.CaptureWithFeedback () [0x00085] in
<64ca337812514938b5bb8fc98fce780b>:0
at Greenshot.Helpers.CaptureHelper.MakeCapture () [0x008a0] in
<64ca337812514938b5bb8fc98fce780b>:0
at Greenshot.Helpers.CaptureHelper.CaptureRegion (System.Boolean
captureMouse) [0x00008] in <64ca337812514938b5bb8fc98fce780b>:0
at Greenshot.MainForm+<>c.<CaptureAreaToolStripMenuItemClick>b__52_0 ()
[0x00000] in <64ca337812514938b5bb8fc98fce780b>:0
at System.Windows.Forms.Control.InvokeMarshaledCallbackDo
(System.Windows.Forms.Control+ThreadMethodEntry tme) [0x000c0] in
<d22f8be2dd674c49bd49b314423240b8>:0
at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper (System.Object
obj) [0x00029] in <d22f8be2dd674c49bd49b314423240b8>:0
at System.Threading.ExecutionContext.RunInternal
(System.Threading.ExecutionContext executionContext,
System.Threading.ContextCallback callback, System.Object state, System.Boolean
preserveSyncCtx) [0x00071] in <e70d6e9587d64cb3abb4b3f99bbf5a0d>:0
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext
executionContext, System.Threading.ContextCallback callback, System.Object
state, System.Boolean preserveSyncCtx) [0x00000] in
<e70d6e9587d64cb3abb4b3f99bbf5a0d>:0
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext
executionContext, System.Threading.ContextCallback callback, System.Object
state) [0x0002b] in <e70d6e9587d64cb3abb4b3f99bbf5a0d>:0
at System.Windows.Forms.Control.InvokeMarshaledCallback
(System.Windows.Forms.Control+ThreadMethodEntry tme) [0x0004d] in
<d22f8be2dd674c49bd49b314423240b8>:0
at System.Windows.Forms.Control.InvokeMarshaledCallbacks () [0x0008a] in
<d22f8be2dd674c49bd49b314423240b8>:0
Terminal output:
0024:fixme:dwmapi:DwmGetWindowAttribute (0003008E 9 0021DA80 16) stub
0024:fixme:uiautomation:UiaClientsAreListening ()
0024:fixme:dwmapi:DwmGetWindowAttribute (00050086 9 0021D620 16) stub
0024:fixme:dwmapi:DwmGetWindowAttribute (00050070 9 0021C850 16) stub
Additional info:
seems to happen on NET 4.5 and Mono 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.
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.
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=55258
Bug ID: 55258
Summary: steam: small window floating on top of all windows
even in fullscreen mode
Product: Wine
Version: 8.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: idarktemplar(a)mail.ru
Distribution: ---
Created attachment 74873
--> https://bugs.winehq.org/attachment.cgi?id=74873
steam_window_bug.png
When running steam with new versions of wine, I'm getting a small square window
which is always on top of all windows, even when I'm playing fullscreen game.
It's usually located around center of screen for me, but during bisecting I
also got a few builds when it appeared at top left corner.
I've tested it with following wine versions:
wine 7.0.2: win7 prefix: good
wine 7.0.2: win10 prefix: does not start
wine 8.0.1: win7 prefix: good
wine 8.0.1: win10 prefix: good
wine 8.9: win10 prefix: bad
wine 8.12: win10 prefix: bad
After that I ran git bisect with following build:
mkdir build32 build64
cd build64
../configure --with-mingw --enable-win64 --prefix=/tmp/wineinstall
cd ../build32
../configure --with-mingw --with-wine64=../build64 --prefix=/tmp/wineinstall
cd ../build64
make $JOBS
cd ../build32
make $JOBS
make $JOBS install
cd ../build64
make $JOBS install
My results are:
2504a2d7bca47fc77bb523114d7b0b6e60213116 is the first bad commit
commit 2504a2d7bca47fc77bb523114d7b0b6e60213116
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Mon Mar 27 11:58:50 2023 +0200
imm32: Keep the IME UI window on the default input context.
dlls/imm32/imm.c | 61 ++++++++++++++++++++++++++++++++------------------------
1 file changed, 35 insertions(+), 26 deletions(-)
$ git bisect log
# bad: [9ffeb2622d087a6189ca916553529824791010c3] Release 8.9.
# good: [d8b2687760f7c07eaf481aba2835b820d3092b3e] Release 8.0.1.
git bisect start 'wine-8.9' 'wine-8.0.1'
# skip: [6677c044abb711f423fadfb61f2c9a37da6ff686] Release 8.0.
git bisect skip 6677c044abb711f423fadfb61f2c9a37da6ff686
# good: [7771a9ae79930d112051cfe18b27dec1e5edd245] widl: Simplify attribute
creation with either int or ptr value.
git bisect good 7771a9ae79930d112051cfe18b27dec1e5edd245
# bad: [d1c317720ab6a92811c013408844ffd9e581b2a2] mfreadwrite: Fix an address
of operator typo.
git bisect bad d1c317720ab6a92811c013408844ffd9e581b2a2
# bad: [66bef6db20f72e88a38c4b264e13639015d7817d] msvcrt: Use the sinhf()
implementation from the bundled musl library.
git bisect bad 66bef6db20f72e88a38c4b264e13639015d7817d
# bad: [17fbef91929af9c6ab98e53fb2a54942f0f1a0a5] wmvcore/tests: Don't cast
NULL to another pointer type.
git bisect bad 17fbef91929af9c6ab98e53fb2a54942f0f1a0a5
# skip: [83f0862b43f7b1b7bd23830b4339894c35febea7] wineps: Handle
EMR_SETARCDIRECTION record in spool files.
git bisect skip 83f0862b43f7b1b7bd23830b4339894c35febea7
# good: [6a88500af29b82040f0518eb87171ca047fb95aa] hidparse.sys: Include
zero-count reports in cap count.
git bisect good 6a88500af29b82040f0518eb87171ca047fb95aa
# good: [62ef3c5be1d2c5374399984588a9daa75663d030] taskkill: Factor out
get_task_pid().
git bisect good 62ef3c5be1d2c5374399984588a9daa75663d030
# bad: [956541c9c823fb6048047893545dcee4c108730e] d3d10/effect: Add support for
umin/umax instructions.
git bisect bad 956541c9c823fb6048047893545dcee4c108730e
# good: [4b04d357739f261457316d55b79ecbcff9c0be84] imm32/tests: Add explicit
ImmLoadIME / ImmFreeLayout calls.
git bisect good 4b04d357739f261457316d55b79ecbcff9c0be84
# bad: [2504a2d7bca47fc77bb523114d7b0b6e60213116] imm32: Keep the IME UI window
on the default input context.
git bisect bad 2504a2d7bca47fc77bb523114d7b0b6e60213116
# good: [9117ce4185146a5edd47467d370b3e4dfa588191] imm32/tests: Test
ImmProcessKey with the installed IME.
git bisect good 9117ce4185146a5edd47467d370b3e4dfa588191
# good: [43e22eaa76a443e3053868df1bd8c5d4130a9fde] imm32/tests: Test IME UI
window and IME window presence.
git bisect good 43e22eaa76a443e3053868df1bd8c5d4130a9fde
# good: [0ddad3564f3260f53e5a50b615f6aa6ba27e032b] imm32: Update existing input
contexts on layout change.
git bisect good 0ddad3564f3260f53e5a50b615f6aa6ba27e032b
# first bad commit: [2504a2d7bca47fc77bb523114d7b0b6e60213116] imm32: Keep the
IME UI window on the default input context.
OS: Gentoo Linux Amd64
Kernel: 6.1.38-gentoo
DE: KDE 5.27.5
glxinfo:
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 7900 XTX (gfx1100, LLVM 16.0.6, DRM 3.49,
6.1.38-gentoo.65)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.3
OpenGL core profile shading language version string: 4.60
--
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=55291
Bug ID: 55291
Summary: gdi32:dc - print_something() gets a bad signature on
fg-deb64-*
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
gdi32:dc - print_something() gets a bad signature on fg-deb64-*:
dc.c:1501: Test failed: wrong signature:
See https://test.winehq.org/data/patterns.html#gdi32:dc
This does not depend on bitness, happens systematically and a bisect shows that
the failure started with the commit below:
commit d5373ef6f92d36971859db0746600188ada22a7d
Author: Piotr Caban <piotr(a)codeweavers.com>
Date: Sun Jul 9 13:05:42 2023 +0200
wineps: Buffer data sent to printer port.
--
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=55231
Bug ID: 55231
Summary: Warframe: camera/mouse stuck in X-axis
Product: Wine
Version: 8.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: pmargeti34(a)gmail.com
Distribution: ---
Wine 8.12 introduces a regression in Warframe: there seems to be a hard limit
to how much camera can be turned on the X-axis. After spinning the camera in
the same direction a few times, it gets stuck and it's no longer possible to
turn in in that direction until it is first turned in the opposite direction.
This happens when Warframe is either in full screen mode or borderless
fullscreen mode. Windowed mode isn't affected.
Warframe is a free to play game and the installer can be obtained here:
https://www.warframe.com/download
OS: Archlinux Linux 6.4.3
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55449
Bug ID: 55449
Summary: Yaesu Wires-X offline and no internet
Product: Wine
Version: 8.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: oleacc
Assignee: wine-bugs(a)winehq.org
Reporter: michael.vencio(a)gmail.com
Distribution: ---
Created attachment 75008
--> https://bugs.winehq.org/attachment.cgi?id=75008
debug output
Yaesu Wires-X is an amateur radio application
https://www.yaesu.com/jp/en/wires-x/index.php
the application is installed and running but cannot connect to the internet.
attached is the debug log file.
--
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=34374
Bug #: 34374
Summary: Mac driver does not respect "Emulate a virtual
desktop" option
Product: Wine
Version: 1.7.0
Platform: x86
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winemac.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: samael5(a)verizon.net
Classification: Unclassified
The Mac driver launches all apps in fullscreen mode, regardless of whether
"Emulate a virtual desktop" is set. Virtual desktop still functions as expected
when using the X11 driver on Mac.
--
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.