https://bugs.winehq.org/show_bug.cgi?id=52865
Bug ID: 52865
Summary: windows.media.speech:speech has a Windows 10
1507-specific failure
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
IAsyncOperation_SpeechRecognitionCompilationResult_get_Completed() unexpectedly
returns a handle on Windows 10 1507:
speech.c:979: Test failed: Handler had value 0029FC20.
https://test.winehq.org/data/patterns.html#windows.media.speech:speech
Unsurprisingly a bisect shows that the failures started with the commit that
introduced this new test:
commit 4926bb148b049f1b60e57091f4aa87a3957aa69e
Author: Bernhard Kölbl <besentv(a)gmail.com>
Date: Wed Apr 6 18:28:41 2022 +0200
windows.media.speech: Add tests for IAsyncOperation.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
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=52845
Bug ID: 52845
Summary: Recent versions of chromium have broken sandbox again
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Somewhere between
chromium-946247 (commit 4e7609b62147866fb7b226fd6efbe1ae4d2f1aca
and
chromium-946263 (commit 1bd694702105072e57b980512130a3212675ec19)
the sandbox got changes so it doesn't work under wine anymore. Result is a
black screen and soon a crash.
This affects both 32bit and 64bit chromium.
Note: chromium should be located inside the WINEPREFIX, it won't run outside!
Nightly versions to test with (chrome-win.zip)
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h…https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h…
I tried to build from source on my Win11 machine, but those versions don't run
under wine at all, even if compiling the same commit as the nightly versions.
--
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=52554
Bug ID: 52554
Summary: Serbian locale mapping cause crash on multiple
installshield wizards
Product: Wine
Version: 7.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: lei.pero(a)gmail.com
Distribution: ---
Since commits:
kernelbase: Map LANG_SERBIAN_NEUTRAL in ConvertDefaultLocale().
f51e44c1802338cdd41b38efe2757b642b619d6f
ntdll: Map LANG_SERBIAN_NEUTRAL in RtlLocaleNameToLcid().
db3e08770fe9bfb6f06a71761e48a40fe9764058
starting with wine-6.2 - when using locale sr_RS.UTF-8, some (specifically
older) installers do crash, for example 3DMark03, preventing installation,
passing LANG=en_US.UTF-8 EV works as expected with no crash.
Reverting those two specific commits solves the issue. Or changing line in:
dlls/ntdll/locale.c
from:
case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ):
*lcid = LANG_SERBIAN_NEUTRAL;
to:
case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ):
*lcid = MAKELCID( 0x02, SORT_DEFAULT );
solves the issue as well, but that basically renders all those commits useless
I assume?
On the topic, but unrelated to this bug, I can see changes in
dlls/kernel32/nls/srl.nls, with commit:
kernel32: Update sr-Latn locale definition.
3b3dfda59951b0f42e297f2b9a31ded04a98d4b4
that doesn't seem right to me, srl.nls should stand for Serbian Latin I assume,
srm.nls probably stands for m as Montenegro. So, if I'm correct, addition of
srm.nls with commit:
kernel32: Add sr-Latn-RS locale definition.
db2666e9d20f80968ff6b4b0ea1deae20c3c368b
should have changes made to srl.lns.
I don't know how this is solved for English for example, since neutral should
have a specific code not related to any country where language is used (e.g.
US, UK, CA etc.), and the code it seems to be sr_CS as it is changed for sr_RS
latin locale, where it shouldn't be changed I assume.
--
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=51181
Bug ID: 51181
Summary: d3d10core:d3d10core fails systematically on AMD GPUs
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_instanced_draw() fails systematically in d3d10core:d3d10core on AMD GPUs
(and sometimes there is a crash that follows):
d3d10core.c:9275: Test failed: Got 0xfff0f010, expected 0xff80f010 at (160, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xfff0f040, expected 0xff80f040 at (240, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaacc, expected 0xffbbaacc at (480, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaa90, expected 0xffbbaa90 at (560, 0),
sub-resource 0.
Notice how this failure does not happen on the machines that have other GPUs
such as cw-gtx560 or QEmu VMs, and how this does not depend on the Windows
version or Radeon driver version for that matter:
https://test.winehq.org/data/patterns.html#d3d10core:d3d10core
So it looks like the test expects fails to account for the Radeon driver
results for some reason.
The commit that introduced this test is:
commit fcd549345d96109179b125d31baf9e9073ecf643
Author: Józef Kucia <jkucia(a)codeweavers.com>
AuthorDate: Mon Nov 6 10:55:20 2017 +0100
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Mon Nov 6 19:37:09 2017 +0100
d3d10core/tests: Add test for SV_InstanceID.
Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
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=43995
Bug ID: 43995
Summary: Uplay - Assassin's Creed 4 Black Flag won't start
Product: Wine-staging
Version: 2.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mi.bar.2001(a)gmail.com
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Created attachment 59652
--> https://bugs.winehq.org/attachment.cgi?id=59652
Terminal log from `wine AC4BFSP.exe`
After clicking the "Play" button in Ubisoft Game Launcher (or launching `wine
AC4BFSP.exe`), a window pops up informing, that the game is starting, but it
disappears and the game doesn't launch. I don't have the Steam version, just
the Uplay one.
I've set Windows version to XP, wineprefix is 32-bit.
Wine version will probably be visible when I post this, but I'm going to
mention it just to be safe. Using Wine 2.20 staging
--
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=52856
Bug ID: 52856
Summary: kernel32:process fails when Wine has no Unix terminal
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: ---
kernel32:console fails on the TestBot Wine machines:
process.c:1552: Test failed: Opening ConIn
process.c:1553: Test failed: Opening ConOut
process.c:1556: Test failed: Getting sb info
process.c:1557: Test failed: Getting console in mode
process.c:1558: Test failed: Getting console out mode
process.c:212: 5 failures in child process
process.c:1569: Test failed: Getting sb info
process.c:1570: Test failed: Getting console in mode
process.c:1571: Test failed: Getting console out mode
process.c:1582: Test failed: GetLastError: expecting 87 got 12
process.c:1592: Test failed: GetLastError: expecting 87 got 12
process.c:1621: Test failed: Console:SizeX expected 30870, but got 0
process.c:1622: Test failed: Console:SizeY expected 31489, but got 0
process.c:1623: Test failed: Console:CursorX expected 32644, but got 0
process.c:1624: Test failed: Console:CursorY expected 94, but got 0
process.c:1625: Test failed: Console:Attributes expected 0, but got 1
process.c:1626: Test failed: Console:winLeft expected 0, but got 1
process.c:1627: Test failed: Console:winTop expected 4294964424, but got 0
process.c:1628: Test failed: Console:winRight expected 49, but got 0
process.c:1629: Test failed: Console:winBottom expected 30870, but got 0
process.c:1630: Test failed: Console:maxWinWidth expected 31489, but got 0
process.c:1631: Test failed: Console:maxWinHeight expected 11256, but got 0
process.c:1634: Test failed: Console:InputMode expected 0, but got 1
process.c:1635: Test failed: Console:OutputMode expected 7211040, but got 0
process.c:1639: Test failed: Wrong console CP (expected 1252 got 0/0)
process.c:1640: Test failed: Wrong console-SB CP (expected 1252 got 0/0)
process.c:1645: Test failed: Wrong console mode
process.c:1646: Test failed: Wrong console-SB mode
https://test.winehq.org/data/patterns.html#kernel32:process
The reason is that the TestBot starts Wine from a daemon process which does not
have an associated xterm / Konsole / GNOME terminal. This causes Wine to have
to allocate a Wine console and that's when things go wrong.
A bisect shows that the TestBot is only impacted by this bug since the commit
below:
commit eff83cd4e00e8ccd4daad05bdd6d76e77664ddd1
Author: Eric Pouech <eric.pouech(a)gmail.com>
Date: Mon Apr 11 15:05:09 2022 +0200
kernelbase: Provide a pseudo console environment for initial CUI processes
not tied to a Unix tty.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52771
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52761
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52743
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
But as the commit entry shows this commit also fixed a lot of other issues in
the TestBot results (not least of which is getting the wow64 WineTest results
in an acceptable shape for test.winehq.org).
Also this issue has happened before as evidenced by bugs 25284 and 28220.
However those bugs are very old (~2014) so the issue may have been fixed and
reappeared (the TestBot has not used a Unix terminal to run the Wine tests
since at least 2018-06 (date on local-testagentd.service) and probably 2017 or
more (f1d368722b65 tools commit)).
Bug 28220 does have a more recent and interesting comment by Esme with regards
to handle inheritance:
https://bugs.winehq.org/show_bug.cgi?id=28220#c3
--
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=52559
Bug ID: 52559
Summary: kernel32:resource times out since 2021-12-29 at two
win10 testbot systems.
Product: Wine
Version: 7.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
Distribution: ---
I wondered because the windows test patterns showed timeouts for
the kernel32:resource [1] since some days.
I tried a run with verbose timestamps and got [2].
There it shows gaps of ~6 seconds, and it looks like the delay
originates from an execution of EndUpdateResourceA [3].
Unfortunately there are a lot calls for this function and
therefore the test times out.
Searching the net led me to the autohotkey forums where this function
was associated with windows defender.
Is windows defender active at these VMs?
[1] https://test.winehq.org/data/tests/kernel32:resource.html
[2] https://testbot.winehq.org/JobDetails.pl?Key=108231&f201=exe32.report#k201
[3]
https://source.winehq.org/git/wine.git/blob/781277de62822c2bac23dc892a99665…
--
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=52079
Bug ID: 52079
Summary: oleacc:main crashes randomly on Windows 10 1709+
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: oleacc
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
oleacc:main crashes randomly on Windows 10 1709+ in both 32- and 64-bit:
main.c:1041: Test failed: V_VT(&v) = 0
main.c:1048: Test failed: V_VT(&v) = 0
main.c:1049: Test failed: V_DISPATCH(&v) = 0000000000000000
main.c:1049: this is the last test seen before the exception
1050:main: unhandled exception c0000005 at 0000000000401597
oleacc:main:1050 done (-1073741819) in 0s
Test failed: crash (c0000005)
https://test.winehq.org/data/patterns.html#oleacc:main
Unsurprisingly a bisect shows that the tests started failing with the commit
that introduced the test:
commit 1a3db363c6b4065af532a8db1e6309be753b1781
Author: Connor McAdams <cmcadams(a)codeweavers.com>
Date: Mon Sep 20 18:03:31 2021 +0200
oleacc: Add Client_get_accFocus tests.
Signed-off-by: Connor McAdams <cmcadams(a)codeweavers.com>
Signed-off-by: Piotr Caban <piotr(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
At the time the crash happened after line 1037 which points to line 1039 as a
likely culprit:
1032 /* Set focus to each child window. */
1033 SetFocus(btn);
1034 hr = IAccessible_get_accFocus(acc, &v);
1035 ok(hr == S_OK, "hr %#x\n", hr);
1036 ok(V_VT(&v) == VT_DISPATCH, "V_VT(&v) = %d\n", V_VT(&v));
1037 ok(V_DISPATCH(&v) != NULL, "V_DISPATCH(&v) = %p\n", V_DISPATCH(&v));
1038
1039 hr = IDispatch_QueryInterface(V_DISPATCH(&v), &IID_IOleWindow,
(void**)&ow);
1040 ok(hr == S_OK, "got %x\n", hr);
That call has been moved to _check_acc_hwnd() and so the crash now happens in
the first QueryInterface() call in that function:
hr = IUnknown_QueryInterface(unk, &IID_IOleWindow, (void**)&ow);
called from
check_acc_hwnd((IUnknown*)V_DISPATCH(&v), btn);
--
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=52904
Bug ID: 52904
Summary: kernel32:locale breaks oleaut32:varformat on Wine in
the French locale
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: ---
kernel32:locale breaks oleaut32:varformat on Wine in the French locale:
varformat.c:642: Test failed: Unexpected hr 0x80020005 for L"0,000 EUR"
varformat.c:649: Test failed: Unexpected hr 0x80020005 for L"0,000 EUR"
https://test.winehq.org/data/patterns.html#oleaut32:varformat
When starting from a clean wineprefix one would normally get "0,000 €" for this
test. But if one runs kernel32:locale before the Euro symbol is replaced with
"EUR" which is then not recognized as a currency symbol.
A bisect shows that the failures started with this commit:
commit 78a33f968461fa3a01d3eec837b4c24f353bc00b
Author: Alexandre Julliard <julliard(a)winehq.org>
AuthorDate: Tue Mar 29 22:12:25 2022 +0200
kernelbase: Reimplement SetLocaleInfoW().
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
The commit modifies both kernel32 and kernel32:locale, and both parts of the
patch are needed to reproduce the failure.
--
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=52867
Bug ID: 52867
Summary: System.Globalization.CultureInfo.GetCultureInfo fails
for 'en' value
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
Distribution: ---
Created attachment 72261
--> https://bugs.winehq.org/attachment.cgi?id=72261
stacktrace
(filing under ntdll, as that where relevant files were before the commit series
that most likely broke it)
After upgrading to 7.6, still occurring in 7.7, a regression was made - the
last published dnSpy version had been running relatively well in its basic
functionality (I'm actually not any good with it), other than minor display
glitches; now it stacktraces immediately.
I believe the stacktrace makes it clear what happens and why I suspect that
locale commit series are at fault here. That release of dnSpy embeds its mono
environment, so it's not a wine-mono problem.
--
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.