wine-bugs July 2022

wine-bugs@winehq.org

1 participants
3865 discussions

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

05 Feb '23

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 04 Feb '23

04 Feb '23

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 21158] New: Hitman: Contracts ignores mouse press events
by wine-bugs＠winehq.org 04 Feb '23

04 Feb '23

http://bugs.winehq.org/show_bug.cgi?id=21158 Summary: Hitman: Contracts ignores mouse press events Product: Wine Version: 1.1.35 Platform: x86 URL: http://www.gamershell.com/download_5663.shtml OS/Version: Linux Status: NEW Keywords: download, regression Severity: minor Priority: P2 Component: directx-dinput AssignedTo: wine-bugs(a)winehq.org ReportedBy: arethusa26(a)gmail.com CC: vitaliy(a)kievinfo.com With wine-1.1.35-180-g20a50f3, after launching Hitman: Contracts, mouse press events at the main menu are ignored by the game. Since a user reported that the game worked normally in wine-1.1.9, a regression test was performed, which indicated: 3743a1a7ca170c765cd779c61b9e362c5b1c5203 is first bad commit commit 3743a1a7ca170c765cd779c61b9e362c5b1c5203 Author: Vitaliy Margolen <wine-patches(a)kievinfo.com> Date: Sun Feb 1 13:11:46 2009 -0700 dinput: Consume mouse & keyboard events in exclusive mode. :040000 040000 6ae6b43b3c100af38ed4f27384470dc4d2595bc1 700b35b9bc8fd27239ee8faaed8ca1c10cfc31d4 M dlls Wine built prior to the indicated commit allows mouse input to work normally. Interestingly, doing graphical mode changes (via keyboard input) makes mouse input work again. The AppDB also suggests adding the strings: UseDirectInputMouse UseDirectInputKeyboard to the HitmanContracts.ini configuration file to have mouse input work. The only visible output under wine-1.1.35-180-g20a50f3 is: fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(1280,1024) fixme:win:EnumDisplayDevicesW ((null),0,0x32eb58,0x00000000), stub! fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub fixme:dsound:DllCanUnloadNow (void): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub (Z:\code\hitman2\gui\MainMenu.cpp:554)Hitman Contracts build 171 (Apr 26 2004 14:42:27) fixme:dsound:DllCanUnloadNow (void): stub -- 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 17

[Bug 50129] New: Calibre-portable error initializing the bypy frozen importer
by WineHQ Bugzilla 03 Feb '23

03 Feb '23

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 53205] New: user32:input - test_rawinput() has a rare pair of failures in Wine
by WineHQ Bugzilla 02 Feb '23

02 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=53205 Bug ID: 53205 Summary: user32:input - test_rawinput() has a rare pair of failures 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:input - test_rawinput() has a rare pair of failures in Wine: input.c:2784: Test failed: 15: expected WM_INPUT message input.c:2787: Test failed: 15: expected RIM_INPUT message https://test.winehq.org/data/patterns.html#user32:input These failures don't seem to depend on the locale or bitness. But there are only two known instances of these failures in WineTest making them likely to cause false positives (~0.5% failure rate). -- 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 52461] New: The Legend of Heroes: Trails of Cold Steel III usually hangs on exit
by WineHQ Bugzilla 02 Feb '23

02 Feb '23

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 02 Feb '23

02 Feb '23

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 02 Feb '23

02 Feb '23

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 02 Feb '23

02 Feb '23

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 53142] New: ieframe:webbrowser - test_ClientSite() has a rare failure on Windows 10 1809+
by WineHQ Bugzilla 02 Feb '23

02 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=53142 Bug ID: 53142 Summary: ieframe:webbrowser - test_ClientSite() has a rare failure on Windows 10 1809+ 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_ClientSite() has a rare failure on Windows 10 1809+: webbrowser.c:2024: Test failed: count = 3 expected 2 https://test.winehq.org/data/patterns.html#ieframe:webbrowser This failure seems to only happen on the TestBot VMs so maybe QEmu is involved somehow. The failure rate is about 5.7%. -- 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

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 July 2022