May 2023 - Wine-bugs - list.winehq.org

[Bug 34678] New: Not all serial port work in wine
by wine-bugs＠winehq.org 18 Aug '23

18 Aug '23

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.

2 10

[Bug 52474] New: ws2_32:sock fails intermittently - 'Test failed: expected timeout'
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 5

[Bug 54748] New: Greenshot GDI+ status: PropertyNotFound
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 10

[Bug 54831] New: GStreamer gst_init_check() crashes when called from winegstreamer on recent macOS
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 9

[Bug 54546] New: ws2_32:sock - test_write_watch() gets unexpected write counts on Windows 11
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 3

[Bug 52889] New: Freelancer with Crossfire mod crashes on startup
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 8

[Bug 52492] New: stack overflow from GdipFlattenPath
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 22

[Bug 53171] New: advapi32:registry - test_performance_keys() sometimes fails due to time going backwards!
by WineHQ Bugzilla 18 Aug '23

18 Aug '23

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.

1 4

[Bug 44816] New: Cygwin/ MSYS2 `script -e` exit status forwarding randomly returns zero for non zero child process
by wine-bugs＠winehq.org 18 Aug '23

18 Aug '23

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.

2 9

[Bug 30655] New: GRID2: Low (1 - 3) FPS during race, but not in in-game menus.
by wine-bugs＠winehq.org 18 Aug '23

18 Aug '23

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.

2 25