https://bugs.winehq.org/show_bug.cgi?id=54676
Bug ID: 54676
Summary: winetricks --verify dotnet20 (AutoHotKey) fails in a
wow64 build
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: dotnet, download, wow64
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
Created attachment 74190
--> https://bugs.winehq.org/attachment.cgi?id=74190
terminal output
The install itself seems to go okay (at least, it exits successfully in quiet
mode).
Running --verify (which should run the .Net verifier tool) instead just hangs
on:
/opt/oldwownew/wine-8.3/bin/wine y:\ahk\AutoHotkeyU32.exe
C:\windows\Temp\dotnet20.ahk
--
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=55127
Bug ID: 55127
Summary: httpapi:httpapi - test_v2_bound_port() sometimes
succeeds in connecting on Windows 10
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: httpapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on
Windows 10:
httpapi.c:1426: Test failed: Connecting to socket succeeded, 0.
httpapi.c:1427: Test failed: Unexpected error connecting to socket, 0.
See https://test.winehq.org/data/patterns.html#httpapi:httpapi
This failure first happened on 2023-02-09 and has happened 4 times since then:
* 2023-02-09 win22H2_fgtb-w10pro64-32
* 2023-03-30 win22H2_fgtb-w10pro64-32
* 2023-05-30 win2009_newtb-w1064v2009-64
* 2023-06-15 win2009_newtb-w1064v2009-64
--
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=54866
Bug ID: 54866
Summary: ieframe:webbrowser - test_SetQueryNetSessionCount()
sometimes gets an unexpected session count on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ieframe
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an
unexpected session count on Windows:
webbrowser.c:4440: init_count 1
webbrowser.c:4443: Test failed: count = 3
webbrowser.c:4446: Test failed: count = 3
webbrowser.c:4449: Test failed: count = 2
webbrowser.c:4452: Test failed: count = 2
See https://test.winehq.org/data/patterns.html#ieframe:webbrowser
These failures only happen on Windows 10 21H1 to 22H2.
On Windows 10 init_count is either 1 or 2 (on w8adm is can be 0 too), but all
the failures so far happened with an init_count of 1. That said there are also
a lot of successful runs with init_count == 1.
This looks a lot like the browser creates a net session for its own purposes:
* Either init_count is 1 and the extra net session is never created or gets
created after test_SetQueryNetSessionCount() is done so all is fine.
* Or the extra net session is created it before test_SetQueryNetSessionCount()
starts and outlives it so our tests pass.
* Or the extra net session gets created after we get init_count but before the
next test so that all our tests are off by one.
* But it seems the extra net session never gets created after the first
SESSION_INCREMENT test.
Note that on my Windows 10 VM when I start iexplorer.exe by hand and then run
the test I always get init_count == 2. But if IE is not already running I get
init_count == 0.
In any case if it's a race condition I could send a patch to retry a couple of
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.
https://bugs.winehq.org/show_bug.cgi?id=54073
Bug ID: 54073
Summary: ws2_32:sock - test_close_events() sometimes fails in
Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ws2_32:sock - test_close_events() sometimes fails in Wine:
sock.c:6775: Test succeeded inside todo block: event series matches
sock.c:6785: Test failed: got unexpected event 0x20
sock.c:6785: Test failed: event series matches
See https://test.winehq.org/data/patterns.html#ws2_32:sock
This happens in the nightly WineTest runs about twice per month but also
impacts merge requests (for instance MR!1524 and MR!1525 where it happened on
the GitLab CI).
--
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=48621
Bug ID: 48621
Summary: Civilization 6 crashes on startup.
Product: Wine
Version: 5.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: charles2000wang(a)gmail.com
Distribution: ---
Created attachment 66468
--> https://bugs.winehq.org/attachment.cgi?id=66468
Game Log file
Launching the game opens a black window before promptly crashes with the
Firaxis Crash Reporter asking to submit a report. Digging around the game
files, I found a log file (GameOverlayRenderer.log) with messages about
"Aborting HookFunc because pRealFunctionAddr is null" and other errors.
--
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=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=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.