wine-bugs February 2023

wine-bugs@winehq.org

1 participants
3407 discussions

[Bug 53816] New: KartRider: Failed to initialize Nexon Game Security with error code e3010104
by WineHQ Bugzilla 04 Feb '23

04 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=53816 Bug ID: 53816 Summary: KartRider: Failed to initialize Nexon Game Security with error code e3010104 Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: j20001970(a)yahoo.com.tw Distribution: --- The game is unable to get past the initialization stage to login window. How to reproduce the bug: 1. Install the game with PopKart_Setup_<version number>.exe 2. Locate the game directory (the installation path is "C:\Program Files (x86)\Gamania\PopKart\M01" by default) and run KartRider.exe with wine. 3. You will see game splash at the center with "Init...Ok", and Nexon Game Security splash at bottom right, then popup "Nexon Game Security Initialize Error.|Code = e3010104" will show. Game account registration is **NOT** required to reproduce the bug. -- 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 7

[Bug 54291] New: vbscript stuck in endless for loop when UBound on Empty and On Error Resume Next
by WineHQ Bugzilla 04 Feb '23

04 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=54291 Bug ID: 54291 Summary: vbscript stuck in endless for loop when UBound on Empty and On Error Resume Next Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: jsm174(a)gmail.com Distribution: --- I ran across some code similar to the following: WScript.echo "Start" Dim ii Dim tmp Dim vpmMultiLights() : ReDim vpmMultiLights(0) On Error Resume Next For Each tmp In vpmMultiLights For ii = 1 To UBound(tmp) : tmp(ii).State = tmp(0).State : Next Next On Error Goto 0 WScript.echo "Done" In real vbscript, the result is: Start Done In wine vbscript, this code will get stuck in an endless loop. To work around this I hacked UBound to return 0 with VT_EMPTY, but I think real vbscript treats this differently. -- 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 54429] New: Feather Launcher Crashes after checking settings, mods, players etc..
by WineHQ Bugzilla 03 Feb '23

03 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=54429 Bug ID: 54429 Summary: Feather Launcher Crashes after checking settings, mods, players etc.. Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hyper.miniaturki(a)gmail.com Distribution: --- Created attachment 73979 --> https://bugs.winehq.org/attachment.cgi?id=73979 Logs Feather Launcher Crashes after checking settings, mods, players etc.. -- 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 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 54328] New: nsi:nsi - test_tcp_tables() sometimes crashes in Wine
by WineHQ Bugzilla 02 Feb '23

02 Feb '23

https://bugs.winehq.org/show_bug.cgi?id=54328 Bug ID: 54328 Summary: nsi:nsi - test_tcp_tables() sometimes crashes in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- nsi:nsi - test_tcp_tables() sometimes crashes in Wine: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x646c35d0). [...] =>0 0x646c35d0 get_extended_tcp_table+0xd0(table=00B40E40, size=0062FCF4, sort=0, family=0x2, table_class=0x8) [Z:\home\fgouget\wine\winetest\src\dlls\iphlpapi\iphlpapi_main.c:3136] in iphlpapi (0x0062fc48) 1 0x646c7288 GetExtendedTcpTable+0x48(table=00B40E40, size=0062FCF4, sort=0, family=0x2, table_class=TCP_TABLE_OWNER_MODULE_ALL, reserved=0) [Z:\home\fgouget\wine\winetest\src\dlls\iphlpapi\iphlpapi_main.c:3185] in iphlpapi (0x0062fc88) 2 0x00403bc9 in nsi_test (+0x3bc9) (0x0062fd28) See https://test.winehq.org/data/patterns.html#nsi:nsi The crash is specific to my Linux desktop, fg-deb64, most likely because it has other network traffic while the test is running. -- 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 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

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 February 2023