wine-bugs October 2023

wine-bugs@winehq.org

1 participants
2953 discussions

[Bug 23531] New: RmcpLoader does not start
by wine-bugs＠winehq.org 11 Oct '23

11 Oct '23

http://bugs.winehq.org/show_bug.cgi?id=23531 Summary: RmcpLoader does not start Product: Wine Version: 1.2-rc6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: i386dx(a)hotmail.com Created an attachment (id=29379) --> (http://bugs.winehq.org/attachment.cgi?id=29379) Backtrace after loading This is about a small tool called 'RmcpLoader'. This is used to monitor and control Newtec devices. The tool can be downloaded (freeware) at http://www.newtec.eu/fileadmin/user_upload/product_leaflets/Rmcploader_v4.9… *Installation works *first attempt gives an error (System error &H8007007E). Nothing to worry about since this is the same behaviour as in Windows (MS Office needs to be installed - can be removed afterwards) After installation of MSOffice 2000/XP/2003 (at this point the program works in Windows) the tool crashes completely. Backtrace attached -- 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 8

[Bug 55762] New: mshtml:script - test_sync_xhr() sometimes gets events in unexpected order in Wine
by WineHQ Bugzilla 10 Oct '23

10 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55762 Bug ID: 55762 Summary: mshtml:script - test_sync_xhr() sometimes gets events in unexpected order in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- mshtml:script - test_sync_xhr() sometimes gets events in an unexpected order in Wine: script.c:4710: Running xhr.js script in 9 mode... script.c:4266: Test marked todo: tymed = 1 [...] script.c:1141: Test failed: L"/index.html?xhr.js: [iframes 2] unexpected order: 0,1,echo,sync_xhr(pre-send),sync_xhr(DONE),sync_xhr" or script.c:4710: Running xhr.js script in 10 mode... script.c:4266: Test marked todo: tymed = 1 [...] script.c:1141: Test failed: L"/index.html?xhr.js: [iframes 2] unexpected order: 0,1,echo,sync_xhr(pre-send),sync_xhr(DONE),sync_xhr,blank(DONE)" or script.c:4710: Running xhr.js script in 11 mode... script.c:1141: Test failed: L"/index.html?xhr.js: [iframes 2] unexpected order: 0,1,echo,sync_xhr(pre-send),sync_xhr(DONE),sync_xhr,blank(DONE)" See https://test.winehq.org/data/patterns.html#mshtml:script Somehow these never happen on the TestBot VMs but they happen regularly on my fg-deb64 development machine, fgtb test VMs and on Remi's cloud Linux test configurations. On 2023-10-09 it also impacted MR!4050 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.

1 2

[Bug 55768] New: gdi32:driver - test_D3DKMTCheckOcclusion() sometimes gets unexpected success on Windows
by WineHQ Bugzilla 10 Oct '23

10 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55768 Bug ID: 55768 Summary: gdi32:driver - test_D3DKMTCheckOcclusion() sometimes gets unexpected success on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com gdi32:driver - test_D3DKMTCheckOcclusion() sometimes gets unexpected success on Windows: driver.c:770: Test failed: Got unexpected return code 0. driver.c:784: Test failed: Got unexpected return code 0. driver.c:789: Test failed: Got unexpected return code 0. See https://test.winehq.org/data/patterns.html#gdi32:driver Where 0 == STATUS_SUCCESS The test expects success in dual screen configurations and STATUS_GRAPHICS_PRESENT_OCCLUDED otherwise. The failures all happen when a single-screen configuration gets success instead of the expected occlusion error. That's quite rare and happens irregularly though: * 2023-02-23 win22H2_fgtb-w10pro64-rx550-64 * 2023-03-02 win1507_newtb-w1064v1507-32 * 2023-03-09 win81_newtb-w864-64 * 2023-03-29 win1507_newtb-w1064v1507-32 * 2023-04-18 win1507_newtb-w1064v1507-32 * 2023-09-08 win1507_newtb-w1064v1507-64 * 2023-10-09 win1507_newtb-w1064v1507-64 Maybe it's caused by interference from another test? -- 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 1

[Bug 55767] New: user32:win - test_SC_SIZE() fails with the Wayland driver
by WineHQ Bugzilla 10 Oct '23

10 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55767 Bug ID: 55767 Summary: user32:win - test_SC_SIZE() fails with the Wayland driver Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:win - test_SC_SIZE() fails with the Wayland driver: win.c:12804: Test failed: rect.left = 100 win.c:12806: Test failed: rect.right = 200 See https://test.winehq.org/data/patterns.html#user32:win These failures are systematic (see rbernon-wayland-*) and started on 2023-09-27. -- 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 1

[Bug 55766] New: user32:win - test_SetActiveWindow_0() gets a bad foreground Window in wine
by WineHQ Bugzilla 10 Oct '23

10 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55766 Bug ID: 55766 Summary: user32:win - test_SetActiveWindow_0() gets a bad foreground Window in wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:win - test_SetActiveWindow_0() gets a bad foreground Window in KDE: win.c:3817: Test failed: GetForegroundWindow returned 00180136 win.c:3819: Test failed: GetActiveWindow returned 00180136 win.c:3821: Test failed: GetFocus returned 00180136 See https://test.winehq.org/data/patterns.html#user32:win This is systematic[1] on fg-deb64, my development desktop, maybe because it runs KDE? However it also happens in the GitLab CI, though only when testing MRs, not in the nightly WineTest runs! * 2023-10-09 MR!4055 * 2023-10-05 MR!3994 * 2022-11-14 MR!1342 * 2022-11-13 MR!1341 * 2022-11-10 MR!1326 [1] Actually for the past 8 months fg-deb64 has a total of 2 runs without these failures, out of 635. -- 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 1

[Bug 54870] New: Logos Bible 10 (dotnet 6) crashes trying to load image
by WineHQ Bugzilla 10 Oct '23

10 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=54870 Bug ID: 54870 Summary: Logos Bible 10 (dotnet 6) crashes trying to load image Product: Wine Version: 8.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: johnpgoodman(a)gmail.com Distribution: --- Created attachment 74363 --> https://bugs.winehq.org/attachment.cgi?id=74363 Terminal output with crash info The app crashes when trying to display an image which is embedded at the beginning of a specific book. It may apply to other books if they have embedded images? If you open the book beyond the first page (by moving it there on a windows machine and syncing position) then it will open ok. It's only as the image comes on the screen that there is a crash. You never see the image. Some other books work ok but this one crashes every time so it is likely to do with image file type or possibly whether it is being fetched remotely? Terminal output 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.

1 2

[Bug 53167] New: xaudio2_7:xaudio2 - test_simple_streaming() has a rare failure caused by out-of-order callbacks
by WineHQ Bugzilla 09 Oct '23

09 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=53167 Bug ID: 53167 Summary: xaudio2_7:xaudio2 - test_simple_streaming() has a rare failure caused by out-of-order callbacks Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com xaudio2_7:xaudio2 - test_simple_streaming() has a rare (~4.5%) failure caused by out-of-order callbacks: Mostly xaudio2.c:69: Test failed: Callbacks called out of order: 1 but also sometimes (w8, w8adm, w864, w10pro64-ja, w10pro64-ko): xaudio2.c:69: Test failed: Callbacks called out of order: 3 https://test.winehq.org/data/patterns.html#xaudio2_7:xaudio2 This failure (in the ': 1' version) also happens in Wine at about the same rate (~5%)! -- 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 2

[Bug 55758] New: quartz:filtergraph - test_render_run() sometimes gets a partial render in Wine
by WineHQ Bugzilla 09 Oct '23

09 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55758 Bug ID: 55758 Summary: quartz:filtergraph - test_render_run() sometimes gets a partial render in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- quartz:filtergraph - test_render_run() sometimes gets a partial render in Wine: filtergraph.c:635: Test failed: Got hr 0x40242. filtergraph.c:645: Test marked todo: Got hr 0. filtergraph.c:617: running L"test.mp3" filtergraph.c:624: Tests skipped: L"test.mp3": codec not supported; skipping test filtergraph.c:571: Test failed: Got hr 0x80004005. Unhandled exception: page fault on read access to 0x00000000 in wow64 32-bit code (0x0043afbc). [...] See https://test.winehq.org/data/patterns.html#quartz:filtergraph Where 0x40242 == VFW_S_PARTIAL_RENDER 0x80004005 == E_FAIL The first known instance happened on 2023-08-08 in a merge request (there is no known instance in the previous 6 months). Also it seems to mainly happen in the GitLab CI: * 2023-08-08 MR!3526 * 2023-08-17 linux_rbernon-x11-fvwm-win32 * 2023-10-05 linux_gitlab-debian-32 * 2023-10-06 linux_gitlab-debian-32 -- 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 1

[Bug 55753] New: Fonts on dialog/modal windows are not aliased
by WineHQ Bugzilla 09 Oct '23

09 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55753 Bug ID: 55753 Summary: Fonts on dialog/modal windows are not aliased Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs(a)winehq.org Reporter: jimmyg521(a)gmail.com Distribution: --- Created attachment 75248 --> https://bugs.winehq.org/attachment.cgi?id=75248 Screenshot of application mp3tag with open dialog box showing unalised fonts I'm on a brand new install of MXLinux v23/Debian Bookworm with the latest stable/dev wine using the Debian Bookworm PPA from WineHQ (now after significant trouble-shooting). **Previous install of MXLinux v21 with it's version of wine-staging did not exhibit this behavior.** Current system/wine information: √ ~ > uname -a Linux HOLLIN 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) x86_64 GNU/Linux HOLLIN [uname -a] ~ 23-10-08 4:17PM √ ~ > wine --version wine-8.17 MX-Linux System Report: KDE Plasma 5.27.5; Debian 12.2 CPU: 8-Core Intel Core i7-10700 (-MT MCP-) speed/min/max: 990/800/4800 MHz Kernel: 6.1.0-10-amd64 x86_64 Up: 8d 9h 1m Mem: 6843.1/15775.5 MiB (43.4%) Storage: 19.11 TiB (41.5% used) Procs: 476 Client: Unknown Client: mx-welcome inxi: 3.3.06 ==== Problem is not about an application installing or running, it's about the dialog windows that both Wine itself and applications display. For example, I can run the notepad app from a terminal in any wine prefix (default 64-bit or a new 32-bit)and its fonts on menubar and menus look fine. But if, for example, I select from the menubar File > Open, the fonts on the Open dialog window are not aliased. The dialog itself is fully functional, its only the fonts that are unaliased. WineCfg it turns out is a dialog (modal?) window and it opens with unaliased fonts. No change to any of the fonts listed on the WineCfg Desktop Integration Appearance Theme modify this font behavior. I have: 1. Completely uninstalled the MXLinux v23 default wine (using mc to track down every folder and file to delete them); reinstalled from the MXLinux repos - no change 2. Completely uninstalled again and reinstalled using flatpak version from org.winehq.Wine - no change 3. Completely uninstalled again, added the Debian Bookwork PPAs to install from WineHq - no change 4. Installed from the WineHQ PPA Wine-Dev - no change 5. Googled ad nauseam various combinations of words trying to limit search results to this specific issue, but it's a bit hopeless; most everyone is looking for ways to install fonts or make fonts larger, but that all works fine for me; in fact, on the Winecfg tab for Appearance, the slider is at 144 dpi and the font displayed below the slider is, of course, correctly aliased; just not any of the rest of the fonts used on the Winecfg dialog window or any other dialog window 6. I have made sure that any tahoma, etc. font in my Linux system that might cause some kind of font conflict was deleted and reinstalled using winetricks and rebooted my system - no change 7. I have removed nearly every font from my user /.fonts/ folder and restarted - no change 8. I have used winetricks to set the fontsmooting registry keys - no change 9. I have used winetricks to install most of the avialable fonts - no change 10. I have created test 32-bit and 64-bit prefixes using winetricks and Q4wine - no change; dialog/modal dialog fonts remain unaliases 10. I have added specific values to my local linux install's user .fonts.conf file to force Linux system aliasing and hinting hoping, based on a blog post, this might spill over into wine, and restarted - no change Again - this is not about funcationality - it all works, it's only about the font display of dialog windows; primary windows of apps and Wine system apps (regedit, notepad, control, taskmgr) all load and display fonts as expected until I use File | Open, File | Print, etc. (see attached screen of application mp3tag running in a 32-bit prefix). Why is this a problem? On an HDPI monitor, pencil thin unaliased fonts are very difficult to read. It is a real usability issue. Here is an image of what I'm talking about - the application mp3tag (which I've been using for several years in wine on both Kubutu and MXLinx v21) with the File | Options dialog enabled. If you increase view to 200%, you can clearly see that the font of the dialog is not aliased while the menu font and other fonts in the app UI are. -- 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 1

[Bug 55757] New: The 32-bit kernel32:debugger gets a debugger inactive failure in the new WoW mode on macOS
by WineHQ Bugzilla 08 Oct '23

08 Oct '23

https://bugs.winehq.org/show_bug.cgi?id=55757 Bug ID: 55757 Summary: The 32-bit kernel32:debugger gets a debugger inactive failure in the new WoW mode on macOS Product: Wine Version: unspecified Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The 32-bit kernel32:debugger gets a debugger inactive failure in the new WoW mode on macOS: debugger.c:205: child: crashing... Unhandled exception: page fault on write access to 0x00000000 in segmented 32-bit code (0107:0044d143). Assertion failed: curr_mode == stm_32bit, file ../wine/dlls/dbghelp/cpu_i386.c, line 278 debugger.c:735: Test failed: exit code = c0000354 See https://test.winehq.org/data/patterns.html#kernel32:debugger Where c0000354 == STATUS_DEBUGGER_INACTIVE The failures are systematic but only happen when running the 32-bit test in a Windows-on-Windows wineprefix on macOS. Looking at the pattern one may also think they started on 2023-10-02 but in fact that's just because before that date the WineTest report had so many other errors that test.winehq.org rejected the report. In fact the test was already failing all the way back to at least 2023-09-07 (there is no earlier data). -- 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 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs October 2023