April 2022 - Wine-Bugs - list.winehq.org

[Bug 40569] New: application crashes with exception in ddraw_allocate_handle (win98)
by wine-bugs＠winehq.org Feb. 5, 2023

Feb. 5, 2023

https://bugs.winehq.org/show_bug.cgi?id=40569 Bug ID: 40569 Summary: application crashes with exception in ddraw_allocate_handle (win98) Product: Wine Version: 1.9.9 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be Distribution: --- Created attachment 54407 --> https://bugs.winehq.org/attachment.cgi?id=54407 Terminal output (wine 1.9.9) I get a page fault in 32-bit code when starting a game in TOCA Touring Car Championship. This is an old game that requires windows version <= win98. The demo also has the bug. ---begin quote--- ... wine: Unhandled page fault on read access to 0x00000110 at address 0x7e7fcf1d (thread 0028), starting debugger... Unhandled exception: page fault on read access to 0x00000110 in 32-bit code (0x7e7fcf1d). ... Backtrace: =>0 0x7e7fcf1d ddraw_allocate_handle+0x1d(t=0x10c, object=0x15f960, type=DDRAW_HANDLE_MATERIAL) [/home/olivier/Projets/wine-builds/1.9.9_x86/dlls/ddraw/../../../wine-git/dlls/ddraw/main.c:118] in ddraw (0x0033f478) ... ---end quote--- This is with git wine 1.9.9-35-gbd2999d and no patch. -- 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 16

[Bug 51481] New: Why is the Epson printer printing blank pages?
by WineHQ Bugzilla Feb. 4, 2023

Feb. 4, 2023

https://bugs.winehq.org/show_bug.cgi?id=51481 Bug ID: 51481 Summary: Why is the Epson printer printing blank pages? Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: baroncorrz(a)gmail.com Distribution: --- Epson printer printing blank pages because there must be some problem related to the cartridge ink or the nozzle. The cartridge ink must have been depleted. You need to check the level of ink by comparing the ink level with the marker on the ink tank. If the ink level is low, then it means that you need to put in a new cartridge. If you have an ink tank with a low ink level, then fill the ink tank with the ink. The problem can also be due to the clogging of the nozzle. You need to clean the nozzle if this happens. One of the best ways to prevent this is by giving fewer jobs to the printer. https://www.epsonprintersupportpro.us/blog/printer-printing-blank-pages/ -- 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 50129] New: Calibre-portable error initializing the bypy frozen importer
by WineHQ Bugzilla Feb. 3, 2023

Feb. 3, 2023

https://bugs.winehq.org/show_bug.cgi?id=50129 Bug ID: 50129 Summary: Calibre-portable error initializing the bypy frozen importer Product: Wine Version: 5.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bilbiliblus(a)gmail.com Distribution: --- When I try to run Calibre-portable.exe y have this message: There was an error initializing the bypy frozen importer: <class 'MemoryError'>: Traceback (most recent call last): File bypy-importer.py, line 250, in <module> File bypy-importer.py, line 195, in __init__ It only happens since Calibre changed to version 5 and on. This very morning I've tried with Calibre 5.3 Thank you -- 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 52461] New: The Legend of Heroes: Trails of Cold Steel III usually hangs on exit
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=52461 Bug ID: 52461 Summary: The Legend of Heroes: Trails of Cold Steel III usually hangs on exit Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: NEW Keywords: patch Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Distribution: --- Created attachment 71749 --> https://bugs.winehq.org/attachment.cgi?id=71749 patch mitigating the race To reproduce it's sufficient to install the game from Steam, get into the main menu, and select the "exit" option (page down with the S key then press Enter). Closing the window also works. The hang doesn't happen every time but does happen most times I tested. This is an application bug. There are two threads—a main thread and a worker thread. The main thread closes the handle to a mutex, goes off and does some other things, and then tries to wait on the mutex handle again (with a timeout of INFINITE). The worker thread basically does a timed wait, in a loop, on a set of handles, except that instead of passing a timeout to WaitForMultipleObjects(), it repeatedly creates a non-periodic auto-reset timer object, sets it for 1 ms, and adds it to the wait array, and then closes the handle. Because of the way handles are allocated in Wine (i.e. "lowest slot first"), and because of the specific pattern of handle usage of the program, what usually happens is that when the mutex handle is closed, the value is reused for a timer handle in the worker thread. While the worker thread is sleeping on the timer, the main thread also waits on it, and when the timer fires, it only wakes up the worker thread (which is almost always first in the queue). Closing the handle of a waitable object in Windows doesn't interrupt other waits in progress, and because the timer is non-periodic and auto-reset, the main thread ends up waiting forever. It turns out that Windows doesn't allocate handles like this. Rather, it seems to use a free list, much like we use in other places in Wine: testing shows that handles are always allocated in the reverse order that they are freed, including across multiple threads, and regardless of how many handles were just allocated. Changing Wine to use a free list like this actually does mitigate the problem. Because the worker thread closes its timer handle and then immediately creates a new one, it will almost always get back the same handle value. The main thread will most likely close its mutex handle while the worker thread is still sleeping, with the effect that the mutex handle won't be reallocated and the subsequent wait will return STATUS_INVALID_HANDLE. In theory the potential for the race is still there, however; it's still possible for the mutex handle to be closed after the timer handle is closed but before a new timer is created, in which case the mutex handle value will be reused for the timer value as it is currently. In practice I'm not sure if this happens more than a negligible fraction of the time. I certainly couldn't reproduce it after 6 or so tries, although that's not very many. Note that there are also reports of it hanging on Windows [1]... [1] https://steamcommunity.com/app/991270/discussions/0/2145343189632898904/ -- 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 51313] New: gdi32:driver sometimes fails with a STATUS_GRAPHICS_PRESENT_OCCLUDED error
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=51313 Bug ID: 51313 Summary: gdi32:driver sometimes fails with a STATUS_GRAPHICS_PRESENT_OCCLUDED error Product: Wine Version: 6.10 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 sometimes gets one or two failures like these: https://test.winehq.org/data/patterns.html#gdi32:driver driver.c:649: Test failed: Got unexpected return code 0xc01e0006. driver.c:689: Test failed: Got unexpected return code 0xc01e0006. 0xc01e0006 is STATUS_GRAPHICS_PRESENT_OCCLUDED. This has happened before but the reason for this error was not identified: https://www.winehq.org/pipermail/wine-devel/2019-July/148494.html I initially suspected a leftover window from a previous test, specifically an Internet Explorer first-run dialog. However the screenshots in the TestBot jobs show that this happens even when there is no such dialog (or at least the dialog is gone by the time the tests complete). The failures always happen on the same two lines despite the occlusion status being checked in other places. Also both failures happen right after minimizing the windows. So it seems likely there is a race condition, either in the test or in the underlying API (if so it spans Windows 10 1607 to 2009). -- 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 51040] New: msi:package fails on Windows 10 if privileges not high enough
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=51040 Bug ID: 51040 Summary: msi:package fails on Windows 10 if privileges not high enough Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The following failures only happen if the test is run on a recent enough Windows (i.e. Windows 10) in a user account with too few privileges. package.c:5079: Test failed: Expected "keydata", got "" package.c:5084: Test failed: Expected "field2", got "" package.c:5089: Test failed: Expected "keydata,field2", got "" package.c:5096: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\FileName1", got "" package.c:5107: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\", got "" package.c:5113: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\", got "" package.c:5123: Test failed: Expected "C:\Users\winetest\AppData\Local\", got "" package.c:5136: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\FileName2.dll", got "" package.c:5147: Test failed: Expected "C:\Users\winetest\AppData\Local\Temp\FileName4.dll", got "" package.c:5651: Test failed: Expected , got winetest In particular one can notice this bug on the TestBot's w1064_adm VM. Note however that these tests seem to be run and succeed on wvistaadm and w7u_adm. See: https://test.winehq.org/data/tests/msi:package.html -- 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 47508] New: FL Studio: Pressing backspace while editing the name of something closes edit name window prematurely
by wine-bugs＠winehq.org Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=47508 Bug ID: 47508 Summary: FL Studio: Pressing backspace while editing the name of something closes edit name window prematurely Product: Wine Version: 4.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ajduck(a)outlook.com Distribution: --- Created attachment 64895 --> https://bugs.winehq.org/attachment.cgi?id=64895 A channel highlighted in the channel rack Since Wine 4.9, pressing backspace to remove text while editing the name of something closes the window and sets the name as whatever was in the box usually with one character removed. Before 4.9 pressing backspace only removed a character without closing the window which is correct behaviour. Steps to reproduce: 1. Open FL Studio. 2. Press F6 to open the channel rack. If nothing appears or a window disappeared, press F6 again. 3. There are probably already a few "channels" in the project file (possibly the demo project opened up). See the image attached. You need to hold shift and click on the highlighted bit, which is a channel. (Alternatively right click and select "Rename, color and icon..."). You can pick any channel for this. 4. The edit name window will appear. Type anything, then press backspace to try and remove a character. What is expected: It should remove a character without closing the window, as text editing usually goes. What actually happens: It closes the edit name window. Sometimes pressing backspace again after the edit name window has closed (especially when doing this on the mixer) goes on to close the playlist (the window with a big grid) which is not normal behaviour (doesn't happen before 4.9 either). Pressing backspace usually only changes the snap settings (the little drop down menu at the top panel of the main FL Studio window which has a magnet by it). -- 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

[Bug 52354] New: winemac.drv not functional on non metal GPUs
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=52354 Bug ID: 52354 Summary: winemac.drv not functional on non metal GPUs Product: Wine Version: 6.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)winehq.org Reporter: gcenx83(a)gmail.com Distribution: --- Since wine-6.17 winemac.drv no longer functions on non Metal GPUs this breaks legacy versions of mac OS X below 10.11 and systems that contain GPUs that don't support Metal. -- 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 63

[Bug 51784] New: The dinput8:hid output is too big in Wine
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=51784 Bug ID: 51784 Summary: The dinput8:hid output is too big in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-dinput Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- dinput8:hid outputs ~26kB of data. This is too much and contributes in pushing the WineTest reports above the 1.5MB limit. The traces break down as follows: 0kB failures 25kB todos 0kB traces 0kB test framework (summary lines, etc.) Time to fix Wine to reduce the number of todos! -- 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 6

[Bug 49443] New: Anno 1800: Super slow & bad performance
by WineHQ Bugzilla Feb. 2, 2023

Feb. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=49443 Bug ID: 49443 Summary: Anno 1800: Super slow & bad performance Product: Wine Version: 5.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: holzminister(a)t-online.de Distribution: --- Created attachment 67544 --> https://bugs.winehq.org/attachment.cgi?id=67544 terminal out WineD3D Hi, I tried to run Anno 1800 but unfortunately it runs pretty terrible slow on my end. The game itself seems to work fine. But when loading into a game it takes me about 30 minutes on my machine (The loading screen seems unresponsive for most of the time, animation plays like once every 5 minutes or so). When loaded into a game I get like <10 FPS (DXVK & WineD3D) and you can visible see the assets and texures being loaded when scrolling through the map (DXVK, with WineD3D it is the same, but there are a lot of graphical glitches in addition). The terminal output attached is with WineD3D. If you require more information please let me know and I will try to provide it. my pc Archlinux Ryzen 2700x 32gb ram AMD Vega 56 (Mesa 20.1.1) game and os on ssd Kind 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.

1 4