https://bugs.winehq.org/show_bug.cgi?id=52869
Bug ID: 52869
Summary: kernel32:locale - test_CompareStringA() fails in Wine
in Hindi
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_CompareStringA() started failing in Wine in Hindi recently:
locale.c:1884: Test failed: expected CSTR_LESS_THAN, got 2
locale.c:1886: Test failed: expected CSTR_GREATER_THAN, got 2
https://test.winehq.org/data/patterns.html#kernel32:locale
A bisect shows this failure started with the commit below:
commit 8993e15cfa5b77ac2487239354ffe63bbc5e562d
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Apr 11 17:21:47 2022 +0200
kernelbase: Support UTF-7/8 codepages in get_codepage_table().
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52743
Bug ID: 52743
Summary: regression cannot write to _fdopen'ed stdout
Product: Wine
Version: 7.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xantares09(a)hotmail.com
Distribution: ---
since wine 7.2, opening stdout with _fdopen and printing into it crashes
```
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
int main()
{
FILE * m_stdout = _fdopen(_fileno(stdout), "wb");
fprintf(m_stdout, "foo\n");
fclose(m_stdout);
return 0;
}
$ x86_64-w64-mingw32-gcc main.c
$ wine a.exe
...
wine: Unhandled page fault on read access to 0000000000000050 at address
0000000170059685 (thread 0128), starting debugger...
...
```
For context, this is what qt-xmlpatterns does:
https://github.com/qt/qtxmlpatterns/blob/dev/tools/xmlpatterns/main.cpp#L184
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52362
Bug ID: 52362
Summary: Powershell Core 7 installer hangs forever on Chinese
locale (LC_ALL=zh_Han.UTF-8)
Product: Wine
Version: 7.0-rc3
Hardware: x86-64
URL: https://github.com/PowerShell/PowerShell/releases/down
load/v7.1.5/PowerShell-7.1.5-win-x64.msi
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Hi, someone i was trying to help someone to get this installed and he reported
this to me (I couldn`t reproduce it), that the installer hung for him, and in
fact he found that it was due to the fact he was running with
LC_ALL=zh_Han.UTF-8
I don`t know anything about these chinese locales, but report anyway as could
be a bug in wine (?).
reproduce: LC_ALL=zh_Han.UTF-8 5ine msiexec /i PowerShell-7.1.5-win-x64.msi
A +relay shows it`s looking for files in directory zh-CN which is not there,
though there is zn-Han(s) directories. But just copying zh-Han to zh-CN didn`t
help either.
Anyway, I guess someone with more knowledge about (Chinese) locales would have
lots more clues than i have...
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52149
Bug ID: 52149
Summary: user32:dialog fails in test_DialogBoxParam() on
current Windows 10 21H1
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
user32:dialog fails in test_DialogBoxParam() on current Windows 10 21H1:
dialog.c:1854: Test failed: got 1407
https://test.winehq.org/data/patterns.html#user32:dialog
So instead of failing with an error code of 0, the call below fails with
ERROR_CANNOT_FIND_WND_CLASS... which makes sense?
ret = DialogBoxParamA(GetModuleHandleA(NULL), "TEST_DIALOG_INVALID_CLASS",
0, DestroyDlgWinProc, 0);
It's interesting to note that this failure did not happen on the initial
Windows 10 21H1 test configurations (2021-08-23). As far as I can tell it's
only after KB5006670 was applied (on 2021-10-21) that the test started failing.
Unfortunately this is a cumulative update so it may not help narrow down the
cause very much.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52922
Bug ID: 52922
Summary: The Evil Within crashes before entering the main menu
using Vulkan renderer
Product: Wine
Version: 7.7
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
CC: z.figura12(a)gmail.com
Regression SHA1: e7d86d9c6e58e8e133c606099615b0d9e7940132
Distribution: ---
wine: Unhandled page fault on read access to 00007F3B54255B28 at address
00007F32CDDE5A09 (thread 0740), starting debugger...
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52887
Bug ID: 52887
Summary: Get-Computerinfo from NoPowershell crashes
Product: Wine
Version: 7.7
Hardware: x86-64
URL: https://github.com/bitsadmin/nopowershell/releases/tag
/1.23
OS: Linux
Status: NEW
Keywords: dotnet, download
Severity: normal
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Created attachment 72275
--> https://bugs.winehq.org/attachment.cgi?id=72275
patch
NoPowershell.exe provides a number of commandlets without the need to install
it(https://github.com/bitsadmin/nopowershell/releases/tag/1.23).
Prerequisite: winetricks -q dotnet48
The commandlet Get-Computerinfo acts as replacement of systeminfo.exe
Source:
https://github.com/bitsadmin/nopowershell/blob/master/Source/NoPowerShell/C…
Currently fails with:
Get-ComputerInfo : System.ArgumentOutOfRangeException: Index was out of range.
Must be non-negative and less than the size of
the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument
argument, ExceptionResource resource)
at NoPowerShell.Commands.Management.GetComputerInfo.Execute(CommandResult
pipeIn)
at NoPowerShell.Program.Main(String[] args)
Attached patch fixes it, to run into next bug . Next bugs are some missing
props from various classes. After adding them (albeit quickly with some hacks)
the cmdlet runs.
I attach first three patches, rest follows later.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52847
Bug ID: 52847
Summary: GetACP() returns CP_UTF8 on some debian VM
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: eric.pouech(a)orange.fr
Distribution: ---
wine's tests in kernel32/tests/process.c fail on some Debian VM
(Dhivehi:Maldives and Hindi:India)
debugging it shows:
- conhost (in window.c) aborts at startup because TranslateCharsetInfo(
GetACP() ...) fails in Wine
- both locale return CP_UTF8 from GetACP()
- testing on windows vm (Hindi), show that GetACP() returns 1252 CP
- moreover, testing on Win11 TranslateCharsetInfo( CP_UTF8 ) succeeds
returning the Win11 values for CP_UTF8 in TranslateCharsetInfo let the
kernel32:process run "correctly" (ie no longer showing the specific errors
related to TranslateCharsetInfo)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48045
Bug ID: 48045
Summary: comdlg32:filedlg crashes or times out randomly
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Created attachment 65586
--> https://bugs.winehq.org/attachment.cgi?id=65586
comdlg32:filedlg: Traces to debug random crash / timeouts.
comdlg32:filedlg crashes randomly on all Windows versions from Vista to Windows
8 while Windows 10 (at least 1507, 1709 and 1809) gets random timeouts.
https://test.winehq.org/data/tests/comdlg32:filedlg.html
When successful comdlg32:filedlg does not print much so the standard reports
are pretty much useless to spot the place where the test gets stuck on Windows
10, assuming it gets stuck in a specific place rather than just being slow.
As for the crashes, they don't trigger the tests exc_filter() so there is no
indication of the last successful ok() call. Turning on 'Report successful
tests' may be preventing the crash (or these runs just got lucky).
It's possible to reproduce the crash while adding the traces in the attached
patch. This is not entirely fruitful as the crashes don't seem to always happen
in the same place. test_extension() is the place where most issues happen
though:
https://testbot.winehq.org/JobDetails.pl?Key=59060
-> wvistau64: Crash in test_extension(). Based on the test_extension_helper()
traces, it happened in the loop with i=1 so for "TestFilter
(*.abc;)\0*.abc;\0".
https://testbot.winehq.org/JobDetails.pl?Key=59086
-> w2008s64+exe: Crash on or after test_extension() return
https://testbot.winehq.org/JobDetails.pl?Key=59088
-> wvistau64+exe: Crash in test_DialogCancel()
https://testbot.winehq.org/JobDetails.pl?Key=59091
-> wvistau64_fr: Spent 39s in test_null_filename() but no timeout
https://testbot.winehq.org/JobDetails.pl?Key=59139
-> wvistau64: Crash in test_null_filename()
-> wvistau64_fr: Timeout in test_extension()
filedlg.c:1048: filter=[TestFilter (*.ab?) lpstrDefExt=NULL]
https://testbot.winehq.org/JobDetails.pl?Key=59151
-> wvistau64: Crash in test_extension()
filedlg.c:1048: filter=[TestFilter (*.abc.def)]
-> wvistau64_fr: Timeout in or after test_mru()
filedlg.c:637: 19 test_ok
filedlg.c:904: 29 test_getfolderpath
filedlg.c:986: 30 test_mru
-> w1064v1809_zh_CN: Two failures in test_extension()
filedlg.c:1053: Test failed: TestFilter (*.pt*;*.abc): expected TRUE
filedlg.c:1059: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef,
expected deadbeef.xyz
Memory corruption, maybe happening quite early in the 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.
https://bugs.winehq.org/show_bug.cgi?id=52924
Bug ID: 52924
Summary: Guilty Gear XX #Reload: black screen since wine 5.0
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: s.guidoni(a)tin.it
Distribution: ---
Since wine 5.0 the game "Guilty Gear XX ♯Reload" shows a black screen while
running.
The game starts, the introductory videos are displayed correctly, then the game
runs, but the screen is just black, with some blocky piece of graphics flashing
now and then across the screen. The sound plays, so one can browse the menu,
start a game and so on, but the screen stays black with some bright rectangular
shape flashing around.
The game is based on DirectX 8.1 and the last wine version that works is 4.21.
With wine 4.21, the console output is:
002d:fixme:win:EnumDisplayDevicesW ((null),0,0x33f798,0x00000000), stub!
002f:fixme:d3d:state_linepattern_w Setting line patterns is not supported in
OpenGL core contexts.
002d:err:quartz:GetClassMediaFile Media class not found
002d:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
With wine 5.0.5, it is:
0033:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
0033:fixme:d3d:wined3d_swapchain_init Unimplemented swap effect 0x5.
0035:fixme:d3d:state_linepattern_w Setting line patterns is not supported in
OpenGL core contexts.
0033:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
With wine 7.6, it is:
012c:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0x3.
012c:err:winediag:wined3d_dll_init Using the OpenGL renderer.
012c:fixme:imm:ImeSetActiveContext (0x266c88, 1): stub
012c:fixme:imm:ImmReleaseContext (0002010C, 00266C88): stub
012c:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command
streams.
012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command
streams.
012c:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52871
Bug ID: 52871
Summary: oleaut32:vartest has failures in Wine in the Arabic
and Hebrew locales
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
oleaut32:vartest has failures in Wine in the Arabic and Hebrew locales:
vartest.c:3130: Test failed: VarAbs: expected 0x0,5,1.1, got
0x80020005,8,-1.#IND
vartest.c:4073: Test failed: wrong result 80020005
vartest.c:4188: Test failed: wrong result 80020005
vartest.c:4312: Test failed: wrong result 80020005
vartest.c:4444: Test failed: wrong result 80020005
vartest.c:7785: Test failed: VarCmp: 2|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 3|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 4|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 5|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 6|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 7|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 2|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 3|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 4|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 5|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 6|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 7|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 11|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 14|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 17|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 20|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 11|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 14|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 17|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 20|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 22|0x8000, 8|0x8000: Expected 0x2, got 0x0
https://test.winehq.org/data/patterns.html#oleaut32:vartest
These failures happen in test_VarAbs(), test_VarFix(), test_VarInt(),
test_VarNeg(), test_VarRound() and test_VarCmp() but a bisect shows that they
all start with this commit:
commit ba43e4cfca97a9bba3e6575af82acbf011685862
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Mar 29 22:11:32 2022 +0200
kernelbase: Reimplement number formatting values in GetLocaleInfoW/Ex using
the locale.nls data.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
It should be noted that this commit did fix another set of oleaut32:vartest
failures (which were likely introduced by 2cd33e6b0fd6).
--
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.