wine-bugs March 2023

wine-bugs@winehq.org

1 participants
3438 discussions

[Bug 53682] New: wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=53682 Bug ID: 53682 Summary: wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14 Product: Wine Version: 7.14 Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: PuetzKevinA(a)JohnDeere.com Distribution: --- I recently updated our builds to past wine-7.0, and began encountering a wineboot failure on aarch64 > 0040:err:system:user_check_not_lock BUG: holding USER lock(64) > s\system32\rundll32.exe: /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:400: user_check_not_lock: Assertion `0' failed. > 0040:err:seh:call_function_handlers invalid frame 21f410 (0000000000022000-0000000000120000) > 0040:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. After some bisecting, I narrowed this down to being a regression between 7.13 and 7.14, and then further narrowed it to https://source.winehq.org/git/wine.git/commit/d50112b4b6e82782d3924a8dbd443… Somehow the call to KeUserModeCallback( NtUserLoadSysMenu,... ) at https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82… does not properly return. I think that commit is mostly a false lead though, the translation of syscall NtUserCreateWindowEx to a syscall just exposed a latent bug in KeUserModeCallback/__wine_syscall_dispatcher on aarch64, since having NtUserCreateWindowEx be a syscall means KeUserModeCallback can no longer use its "if we have no syscall frame, call the callback directly" simple path https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar… What seems to be actually at fault is that, inside of User32LoadSysMenu (the actual function invoked by KeUserModeCallback), is a call to NtUserCreateMenu - which is *also* a syscall. This call doesn't crash, and in fact all of User32LoadSysMenu runs to completion. But when it goes through __wine_syscall_dispatcher, the stack pointer is restored to be `$sp = arm64_thread_data()->syscall_frame` https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar… - i.e. it points to &callback_frame, back on the stack of KeUserModeCallback. And this is *not* the bottom of the stack; there's compiler-generated prologue/epilogue to restore various non-volatile registers. 0x0000ffffaa0247b4 <KeUserModeCallback+0>: sub sp, sp, #0x450 0x0000ffffaa0247b8 <KeUserModeCallback+4>: stp x29, x30, [sp] 0x0000ffffaa0247bc <KeUserModeCallback+8>: mov x29, sp 0x0000ffffaa0247c0 <KeUserModeCallback+12>: stp x19, x20, [sp, #16] 0x0000ffffaa0247c4 <KeUserModeCallback+16>: stp x21, x22, [sp, #32] 0x0000ffffaa0247c8 <KeUserModeCallback+20>: str w0, [sp, #56] 0x0000ffffaa0247cc <KeUserModeCallback+24>: str x1, [sp, #48] 0x0000ffffaa0247d0 <KeUserModeCallback+28>: str w2, [sp, #60] 0x0000ffffaa0247d4 <KeUserModeCallback+32>: mov x21, x3 0x0000ffffaa0247d8 <KeUserModeCallback+36>: mov x20, x4 0x0000ffffaa0247dc <KeUserModeCallback+40>: add x19, sp, #0x40 // x19=&callback_frame So any code that runs inside this syscall that uses the first 0x40 bytes of stack is trampling these variables in the frame of KeUserModeCallback. Eventually User32LoadSysMenu returns back into KiUserCallbackDispatcher, which passes it into NtCallbackReturn, which does a __wine_longjmp back into the KeUserModeCallback,and we exit from the __wine_setjmp for the second time (returning 0) and get to `return callback_frame.status` https://gitlab.winehq.org/wine/wine/-/blob/wine-7.17/dlls/ntdll/unix/signal…. But then the epilogue starts peeling off the stack => 0x0000ffffaa024864 <+176>: ldr w0, [sp, #1088] 0x0000ffffaa024868 <+180>: ldp x19, x20, [sp, #16] 0x0000ffffaa02486c <+184>: ldp x21, x22, [sp, #32] 0x0000ffffaa024870 <+188>: ldp x29, x30, [sp] 0x0000ffffaa024874 <+192>: add sp, sp, #0x450 0x0000ffffaa024878 <+196>: ret and the link register $x30 = (void *) 0xffffaa024984 <NtCallbackReturn+104>, rather than 0xffffa8f0ccdc <copy_sys_popup+44> as it was when it was pushed in the prologue. It's overwritten several times along the way, but I don't think any of these call sites are at fault; they are just writing to what they think is their own stack frame, unaware that __wine_syscall_dispatcher adjusted $sp to too-high a value and they are overwriting space that belongs to KeUserModeCallback. The specific places that overwrote this entry on the stack were #0 0x0000ffffa8f37a48 in NtUserCallOneParam (arg=0, code=2) at /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:5357 #1 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to 0xffffaa022cf0 <__wine_syscall_dispatcher+272> #0 insert_menu_item (ret_pos=0x21f538, flags=1024, id=4294967295, handle=0x10042) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:438 #1 NtUserThunkedMenuItemInfo (handle=0x10042, pos=4294967295, flags=1024, method=1, info=0x11f528 <opengl_func_names+680>, str=<optimized out>) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:1297 #2 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to NULL and 0x0000ffffaa023a0c in NtCurrentTeb () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449 1449 { (gdb) bt #0 0x0000ffffaa023a0c in NtCurrentTeb () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449 #1 0x0000ffffaa02493c in ntdll_get_thread_data () at /home/yukondev/workspace/wine/dlls/ntdll/unix/unix_private.h:70 #2 arm64_thread_data () at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:163 #3 NtCallbackReturn (ret_ptr=0x0, ret_len=0, status=65602) at /home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:784 #4 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from /opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so which set it to 0xffffaa02493c <NtCallbackReturn+32>, and then 0xffffaa024978 <NtCallbackReturn+92> , then 0xffffaa024984 <NtCallbackReturn+104> The same sort of thing happens in the x86_64 dispatcher, but there it turns out to be pretty harmless. The key difference is that the function prologue on x86_64 used `push` instructions, and did so prior to the `sub` where it allocated space for locals, so the things popped by the epilogue ended up above callback_frame, rather than below it, and so are not smashed. 0x00007fd17b6dc1d2 <+0>: push %rbp 0x00007fd17b6dc1d3 <+1>: mov %rsp,%rbp 0x00007fd17b6dc1d6 <+4>: push %r14 0x00007fd17b6dc1d8 <+6>: push %r13 0x00007fd17b6dc1da <+8>: push %r12 0x00007fd17b6dc1dc <+10>: push %rdi 0x00007fd17b6dc1dd <+11>: push %rsi 0x00007fd17b6dc1de <+12>: push %rbx 0x00007fd17b6dc1df <+13>: sub $0xa0,%rsp 0x00007fd17b6dc1e6 <+20>: and $0xffffffffffffffc0,%rsp 0x00007fd17b6dc1ea <+24>: sub $0x560,%rsp There is still a 32-byte gap between the $rsp of KeUserModeCallback and &current_frame that is briefly at risk, but 1. This seems to be the register parameter area of the Windows x64 ABI, which is actually volatile space that belongs to the callee even though it's allocated by the caller, so the compiler is not expecting it to survive across function calls (in this case __wine_syscall_dispatcher_return). https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170 discusses how this "contains at least 4 entries", i.e. 32 bytes: https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64 2. It doesn't actually get smashed, because __wine_syscall_dispatcher subtracts 0x20 from the restored $rsp before actually making the syscall (https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…). Which is presumably since the SysV ABI does *not* make any such reservation, and so __wine_syscall_dispatcher needs to do so to be following the ms_abi. So together, these mean that on x86_64, it would be OK if __wine_syscall_dispatcher used these 32 bytes between the correct $rsp of KeUserModeCallback and frame->syscall_table (though it doesn't seem to). And the eventual callee gets a $rsp that does *not* overlap with KeUserModeCallback (even though it would be legal for it to do so). I don't know that we have any actual guarantee that callback_frame will be at the bottom, but in practice it seems to be. But on aarch64, there's important stuff below callback_frame, so this doesn't work out. -- 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 29

[Bug 54442] New: experimental wow64 mode: doesn't show some graphical windows
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=54442 Bug ID: 54442 Summary: experimental wow64 mode: doesn't show some graphical windows Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: idarktemplar(a)mail.ru Distribution: --- Created attachment 73990 --> https://bugs.winehq.org/attachment.cgi?id=73990 SteamSetup.png When I'm building wine with new experimental wow64 mode, it is unable to properly show or render application windows for some applications. I've tried it both on clean prefix and on existing prefix. I've tried Steam setup and Battle.net setup, both failed. With Battle.net setup I see no window, with Steam setup I see black window with some artifacts. When using multilib wine built old way, everything works as usual. Happens both with wine 8.0 and 8.1. OS: Gentoo Linux amd64 (64bit) Graphics: X11 Videocard information: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro K1000M/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 470.161.03 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile Wine build options: ./configure --with-mingw --enable-archs='i386,x86_64' --prefix=/tmp/wineinstall Default wine output: $ WINEPREFIX=/tmp/wineprefix/prefix1 /tmp/wineinstall/bin/wine /tmp/SteamSetup.exe 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0090:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 0034:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 010c:err:environ:init_peb starting L"Z:\\tmp\\SteamSetup.exe" in experimental wow64 mode 010c:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. 010c:fixme:imm:ImeSetActiveContext (00020046, 1): stub 010c:fixme:imm:ImmReleaseContext (00010052, 00020046): stub 0090:fixme:imm:ImeSetActiveContext (0000000000010026, 0): stub 0090:fixme:imm:ImmReleaseContext (0000000000010020, 0000000000010026): stub -- 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 9

[Bug 54751] New: The 64-bit advapi32:registry breaks test_CoGetPSClsid() in ole32:compobj in Wine
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=54751 Bug ID: 54751 Summary: The 64-bit advapi32:registry breaks test_CoGetPSClsid() in ole32:compobj in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The 64-bit advapi32:registry breaks test_CoGetPSClsid() in ole32:compobj in Wine: compobj.c:1449: Test failed: CoGetPSClsid failed with error 0x80040155 compobj.c:1450: Test failed: got clsid {52222222-1234-1234-1234-56789abcdef0} See https://test.winehq.org/data/patterns.html#ole32:compobj A bisect shows that this started with the commit below: commit 3f82f6ff59f4024f67e2d646883cbea223fba84a Author: Sven Baars <sbaars(a)codeweavers.com> Date: Fri Mar 17 16:52:51 2023 +0100 kernelbase: Use open_key() to obtain any existing Wow6432node in create_key(). -- 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 54738] New: msi:action - The 64-bit test_register_class_info() fails in Wine
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=54738 Bug ID: 54738 Summary: msi:action - The 64-bit test_register_class_info() fails in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- msi:action - The 64-bit test_register_class_info() fails in Wine: action.c:6025: Test failed: key not created action.c:6147: Test failed: key not created See https://test.winehq.org/data/patterns.html#msi:action -- 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 48811] New: StarCraft II fails to load in staging, crashes after trying to start a game in stable
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=48811 Bug ID: 48811 Summary: StarCraft II fails to load in staging, crashes after trying to start a game in stable Product: Wine Version: 5.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: wschmrdr(a)gmail.com Distribution: --- Created attachment 66725 --> https://bugs.winehq.org/attachment.cgi?id=66725 Output occurring when the application crashes. Ever since upgrading from 5.3 to 5.4, StarCraft II has ceased working. On staging, this occurs during the loading screen. I am able to get through the Battle.net app OK, but cannot get to my login authenticating. I have tried switching to stable, but when trying to load up a game, I see the same output issue. Selected the dbghelp component because that's the line that comes up in the output at the time of the crash. -- 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 15

[Bug 54742] New: The 64-bit advapi32:registry breaks the 32-bit test_redirection() in Wine
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=54742 Bug ID: 54742 Summary: The 64-bit advapi32:registry breaks the 32-bit test_redirection() in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The 64-bit advapi32:registry breaks the 32-bit test_redirection() in Wine. To reproduce run the following commands: $ rm -rf ~/.wine # start from a fresh wineprefix $ ./wow64/wine64 wow64/dlls/advapi32/tests/x86_64-windows/advapi32_test.exe registry 2>&1 | grep -E '(Test failed|tests executed)' 0020:registry: 6309 tests executed (156 marked as todo, 0 as flaky, 0 failures), 2 skipped. $ ./wow32/wine wow32/dlls/advapi32/tests/i386-windows/advapi32_test.exe registry 2>&1 | grep -E '(Test failed|tests executed)' registry.c:2837: Test failed: RegOpenKeyExA failed: 2 registry.c:2842: Test failed: RegOpenKeyExA failed: 2 registry.c:2861: Test failed: 00000000: wrong value 32/64 registry.c:2863: Test failed: 00000200: wrong value 32/64 registry.c:2868: Test failed: 00000000: wrong value 64/0 registry.c:2869: Test failed: 00000100: wrong value 64/0 registry.c:2870: Test failed: 00000200: wrong value 64/0 registry.c:3168: Test failed: RegOpenKeyExA failed: 2 registry.c:3174: Test failed: RegOpenKeyExA failed: 2 registry.c:3180: Test failed: RegOpenKeyExA failed: 2 registry.c:3206: Test failed: found equals 0 registry.c:3208: Test failed: found equals 0 registry.c:3210: Test failed: found equals 0 registry.c:3212: Test failed: found equals 1 registry.c:3214: Test failed: wrong number of subkeys: 10 registry.c:3216: Test failed: found equals 1 registry.c:3218: Test failed: found equals 0 registry.c:3220: Test failed: wrong number of subkeys: 10 registry.c:3222: Test failed: found equals 0 0128:registry: 7658 tests executed (74 marked as todo, 0 as flaky, 19 failures), 2 skipped. See https://test.winehq.org/data/patterns.html#advapi32:registry The reason why this failure is only visible with the fg-deb64-wow32 is because this is the only test configuration that runs the 32-bit tests in the same wineprefix as the 64-bit tests. What this shows is that advapi32:registry does not correctly cleans up after itself which has the potential for breaking any test that follows (not just 32-bit ones). -- 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 53431] New: widl generates enum forward declarations in typedefs which are not valid in C++
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=53431 Bug ID: 53431 Summary: widl generates enum forward declarations in typedefs which are not valid in C++ Product: Wine Version: 7.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: gfw.kra(a)gmail.com Distribution: --- Hi everyone, I recently discovered an issue with C++ code in headers compiled from winrt idl's using widl. It does not compile when included, when tried using mingw g++ v12.1.0. There’s seems to be issue with how enum typedefs are translated within namespaces. Example: When tried to include windows.media.speechsynthesis.h compiled from windows.media.speechsynthesis.idl in cpp file, the following output is received (compiler output shows headers from mingw, but these look the same when compiled using widl in wine). ``` /usr/x86_64-w64-mingw32/include/windows.foundation.h:90:26: error: use of enum ‘PropertyType’ without previous declaration 90 | typedef enum PropertyType PropertyType; | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.foundation.h:164:18: error: using typedef-name ‘ABI::Windows::Foundation::PropertyType’ after ‘enum’ 164 | enum PropertyType { | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.foundation.h:90:39: note: ‘ABI::Windows::Foundation::PropertyType’ has a previous declaration here 90 | typedef enum PropertyType PropertyType; | ^~~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:30: error: use of enum ‘VoiceGender’ without previous declaration 218 | typedef enum VoiceGender VoiceGender; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:476:22: error: using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after ‘enum’ 476 | enum VoiceGender { | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note: ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration here 218 | typedef enum VoiceGender VoiceGender; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:822:30: error: using typedef-name ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ after ‘enum’ 822 | enum VoiceGender *value) = 0; | ^~~~~~~~~~~ /usr/x86_64-w64-mingw32/include/windows.media.speechsynthesis.h:218:42: note: ‘ABI::Windows::Media::SpeechSynthesis::VoiceGender’ has a previous declaration here 218 | typedef enum VoiceGender VoiceGender; ``` windows.media.speechsynthesis.idl has typedef of enum VoiceGender, which is defined later. ``` namespace Windows { namespace Foundation { interface IClosable; } namespace Media { namespace SpeechSynthesis { typedef enum VoiceGender VoiceGender; ``` This is translated to following: ``` #ifdef __cplusplus namespace ABI { namespace Windows { namespace Media { namespace SpeechSynthesis { typedef enum VoiceGender VoiceGender; } } } } #else /* __cplusplus */ typedef enum __x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender __x_ABI_CWindows_CMedia_CSpeechSynthesis_CVoiceGender; #endif /* __cplusplus */ ``` This typedef is not valid in C++. According to the standard, enum cannot be forward declared using typedef. This could be replaced with just simple enum declaration, but it would need to have type specifier (that goes for definition as well). Best 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 1

[Bug 36079] New: loader fails to build with clang -faddress=sanitize
by wine-bugs＠winehq.org 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=36079 Bug ID: 36079 Summary: loader fails to build with clang -faddress=sanitize Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Keywords: download, source Severity: enhancement Priority: P2 Component: build-env Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Created attachment 48263 --> https://bugs.winehq.org/attachment.cgi?id=48263 make log I tried building wine with clang's address sanitizer enabled, which mostly worked, until the loader: make[1]: Entering directory '/home/austin/wine-gcc49-asan/loader' clang -fsanitize=address -m32 -o wine-preloader -static -nostartfiles -nodefaultlibs -Wl,-Ttext=0x7c400000 preloader.o ../libs/port/libwine_port.a /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../lib32/libpthread.a(pthread_mutex_lock.o): In function `__pthread_mutex_lock': /var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:80: undefined reference to `__assert_fail' /var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:116: undefined reference to `__assert_fail' /var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:146: undefined reference to `__assert_fail' /var/tmp/portage/sys-libs/glibc-2.19/work/glibc-2.19/nptl/../nptl/pthread_mutex_lock.c:151: undefined reference to `__assert_fail' .. austin@aw25 ~/wine-gcc49-asan $ clang --version clang version 3.3 (tags/RELEASE_33/final) Target: x86_64-pc-linux-gnu Thread model: posix austin@aw25 ~/wine-gcc49-asan $ git describe wine-1.7.17-42-g24c5728 -- 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 3

[Bug 49797] New: WIDL doesn't tolerate anonymous structs within interfaces
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=49797 Bug ID: 49797 Summary: WIDL doesn't tolerate anonymous structs within interfaces Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: kolan_n(a)mail.ru Distribution: --- IDLs in Windows SDKs sometimes contain anonymous structs within interfaces. WIDL fails to compile such IDLs. -- 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 2

[Bug 37346] New: New application , installed successfully , starts up fine , no data storing , BUSY WIN ACCOUNTING APP
by wine-bugs＠winehq.org 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=37346 Bug ID: 37346 Summary: New application , installed successfully , starts up fine , no data storing , BUSY WIN ACCOUNTING APP Product: Wine Version: unspecified Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lax.sunny(a)gmail.com Created attachment 49664 --> https://bugs.winehq.org/attachment.cgi?id=49664 Log created by wine on running the app , problem is with database storage and runtime functions Application named busy win very much famous accounting software tried using number of prefixes application installs smoothly when i run the app it starts up normally but crashes on adding a new company or detecting an old DATABASE -- 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 10

[Bug 50079] New: Wine msiexec fails when building inside a windows/mac os x docker container
by WineHQ Bugzilla 23 Jun '23

23 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=50079 Bug ID: 50079 Summary: Wine msiexec fails when building inside a windows/mac os x docker container Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: spam(a)crasu.de Distribution: --- Created attachment 68535 --> https://bugs.winehq.org/attachment.cgi?id=68535 Run with winedebug=msi and strace Sample dockerfile: FROM ubuntu:20.04 RUN export DEBIAN_FRONTEND="noninteractive" \ && dpkg --add-architecture i386 \ && apt-get update \ && apt-get install -y wget winbind xvfb unzip curl jq \ && apt-get remove -y libmysqlclient21 mysql-common \ && apt autoremove -y RUN wget -nc https://dl.winehq.org/wine-builds/winehq.key && apt-key add winehq.key RUN echo 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main' > /etc/apt/sources.list.d/wine.list RUN export DEBIAN_FRONTEND="noninteractive" \ && apt-get update \ && apt-get install -o APT::Immediate-Configure=false --install-recommends -y winehq-devel RUN useradd -ms /bin/bash wineuser # Install winemono RUN wget https://dl.winehq.org/wine/wine-mono/5.1.1/wine-mono-5.1.1-x86.msi RUN WINEPREFIX=/home/wineuser/.wine su wineuser -c "wine msiexec /i wine-mono-5.1.1-x86.msi && wineserver -w" Eroor message: 0024:err:msi:ACTION_InstallFiles compressed file wasn't installed (L"bin\\libmono-2.0-x86.dll") 0024:err:msi:execute_script Execution of script 0 halted; action L"InstallFiles" returned 1603 I tried different msis (wine gecko, wine mono, ....) they all fail. After serveral tries the installation sometimes does not through an error. But the package is still not fully installed. Reference: https://github.com/Winetricks/winetricks/issues/1525 -- 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 51502] New: Civilization 3 Sound Stutters, loops, and fails (eventually)
by WineHQ Bugzilla 22 Jun '23

22 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=51502 Bug ID: 51502 Summary: Civilization 3 Sound Stutters, loops, and fails (eventually) Product: Wine Version: 6.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mountmgr.sys Assignee: wine-bugs(a)winehq.org Reporter: bryan(a)varnernet.com Distribution: --- Audio on Civilization III is just not very good. Typical short sounds stutter, playback sounding badly rendered into the target buffer, loop when they shouldn't, etc. The most common problem is for the sound (all of it) to just stop, or just continuously loop a small soundfile that should have been a one-off play at the triggered point in time. Looks like the app is using dsound, along with winmm to mmioOpenA the .wav's. -- 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 52762] New: DesignDoll will not boot/crashes upon booting.
by WineHQ Bugzilla 22 Jun '23

22 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=52762 Bug ID: 52762 Summary: DesignDoll will not boot/crashes upon booting. Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: catchyandcleche(a)gmail.com Distribution: --- Created attachment 72129 --> https://bugs.winehq.org/attachment.cgi?id=72129 This file (designdoll_backtrace01.txt) is the backtrace file/error log file that was created when I tried to run the DesignDoll application. I am using a GUI version of Ubuntu for Desktop (Ubuntu 20.04.4 LTS), also utilizing WINE version 7.0 (Displayed as wine-7.0 in the terminal). When double clicking the .desktop application created on the desktop (DesignDoll.desktop) after installing the DesginDollLauncher.exe program and after making sure that the DesignDoll.desktop shortcut created during the installation process allows launching, the program will boot* but quickly crash. I attached the program error log (see "designdoll_backtrace01.txt). *I can only assume that the application booted (or at least tried to) and quickly crashed. It did not display any indication that the program had booted in the GUI environment. When a window did show up to indicate that the program had run (in a sense), it was to inform me of the fact that the program crashed (or simply could not boot). -- 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 54271] New: gdiplus:get_gif_background_color can't get gif background color
by WineHQ Bugzilla 21 Jun '23

21 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=54271 Bug ID: 54271 Summary: gdiplus:get_gif_background_color can't get gif background color Product: Wine Version: unspecified Hardware: x86 OS: other Status: UNCONFIRMED Severity: critical Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com Created attachment 73837 --> https://bugs.winehq.org/attachment.cgi?id=73837 wrong picture OS：debian When I was using WeChat, I found that when sending an animated gif, the same image would have different serious errors, such as misalignment, flickering, solid black(sometimes pink, brown) background . I know that using winetricks gidplus can fix this problem, but this method introduces some other problems, so I come here for help hoping to find a solution to the problem. I really need your help! ! ! Maybe you need an account for this application. Of course, it would be great if you can find a similar demo. I am trying to find a demo APP download url：https://weixin.qq.com/ -- 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 11

[Bug 52619] New: Dungeon Fighter Online: Launcher crash when accepting Terms of Service
by WineHQ Bugzilla 20 Jun '23

20 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=52619 Bug ID: 52619 Summary: Dungeon Fighter Online: Launcher crash when accepting Terms of Service Product: Wine Version: 7.2 Hardware: x86-64 URL: https://www.dfoneople.com/support/download OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wannabetheguy(a)gmail.com Distribution: Fedora Created attachment 71944 --> https://bugs.winehq.org/attachment.cgi?id=71944 Terminal log output With Proton 7.0 announcing Dungeon Fighter Online as playable, I gave it a try and ran into this crash when trying to log-in with my old Neople account. Both the Steam version and standalone version of the launcher crashed this way. A clean Wine 7.2 (staging) prefix with the standaline client gives me an identical result, so I am reporting here as well. The problem occurs with NeopleLauncher.exe. After logging in with my Neople account, I am required to accept the Terms of Service that appears within the window before being able to continue. When I click the Accept button, the launcher crashes. On subsequent log-ins, the Terms of Service appears again. The only change to the Wine prefix was changing the Windows version to 10 as the launcher gives a "no longer supported" message with 7. 8/8.1 work but crash the same as 10. The ieframe messages just before the backtrace seem notable, but as I'm not sure I have set this report to unknown. -- 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 31

[Bug 27232] New: keys stuck when wine window loses focus
by wine-bugs＠winehq.org 19 Jun '23

19 Jun '23

http://bugs.winehq.org/show_bug.cgi?id=27232 Summary: keys stuck when wine window loses focus Product: Wine Version: 1.3.19 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: hramrach(a)gmail.com When a key is pressed while a wine application is in focus and released while other application has focus it is stuck down in wine. To reproduce: 0) set your window manager to focus follows mouse 1) run notepad 2) press some keys to type text 3) press and hold ctrl, pressing a now selects typed text 4) move the mouse to another window 5) release ctrl 6) move mouse back to notepad, press a Now text previously selected should be replaced with a. Instead, it is selected again by the Ctrl+a shortcut. The Ctrl key is stuck. Note that when windows are switched by means similar to Windows ALt+Tab the modifier used for switching windows this way gets also stuck. -- 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 33

[Bug 50431] New: SCM erroneously tries to start 64-bit kernel drivers as 32-bit service when 'ImagePath' contains '\\SystemRoot\\system32\\drivers' and 'WOW64=1'
by WineHQ Bugzilla 19 Jun '23

19 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=50431 Bug ID: 50431 Summary: SCM erroneously tries to start 64-bit kernel drivers as 32-bit service when 'ImagePath' contains '\\SystemRoot\\system32\\drivers' and 'WOW64=1' Product: Wine Version: 6.0-rc4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. Bug 47175 (https://bugs.winehq.org/show_bug.cgi?id=47175#c4) is kinda related but the mistake is not in the service creation part. Norton AntiVirus 2010 installer creates several 32-bit and 64-bit services. The kernel driver services are 64-bit by design (64-bit WINEPREFIX). The registry entries for these services contain a mix of different styles. 'WOW64' is always set because the services were created by a 32-bit installer process. Wine uses this flag only in case of failure to determine the binary type. 64-bit kernel drivers should be always started as 64-bit. Registry: --- snip --- ... [System\\CurrentControlSet\\Services\\BHDrvx64] 1609425565 "Description"="SONAR Engine Driver" "DisplayName"="BHDrvx64" "ErrorControl"=dword:00000001 "ImagePath"="C:\\ProgramData\\Norton\\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\\NAV_17.0.0.136\\Definitions\\BASHDefs\\20090829.001\\BHDrvx64.sys" "ObjectName"="LocalSystem" "PreshutdownTimeout"=dword:0002bf20 "Start"=dword:00000003 "Type"=dword:00000001 "WOW64"=dword:00000001 ... [System\\CurrentControlSet\\Services\\IDSVia64] 1609419518 "Description"="Symantec Intrusion Prevention Driver" "DisplayName"="IDSVia64" "ErrorControl"=dword:00000001 "ImagePath"="C:\\ProgramData\\Norton\\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\\NAV_17.0.0.136\\Definitions\\IPSDefs\\20090828.002\\IDSVia64.sys" "ObjectName"="LocalSystem" "PreshutdownTimeout"=dword:0002bf20 "Start"=dword:00000001 "Type"=dword:00000001 "WOW64"=dword:00000001 ... [System\\CurrentControlSet\\Services\\ccHP] 1609437834 #time=1d6df9f4d82eda4 "DisplayName"="Symantec Hash Provider" "ErrorControl"=dword:00000001 "ImagePath"="\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys" "ObjectName"="LocalSystem" "PreshutdownTimeout"=dword:0002bf20 "Start"=dword:00000001 "Type"=dword:00000001 "WOW64"=dword:00000001 ... --- snip --- 'ccHP' kernel service doesn't work here. SCM erroneously starts 'winedevice' hosting process as 32-bit hence loading the 64-bit kernel driver binary will obviously fail. --- snip --- $ pwd /home/focht/.wine/drive_c/windows/system32/drivers/NAVx64/1100000.088 $ file * cchpx64.cat: data ccHPx64.inf: Windows setup INFormation ccHPx64.sys: PE32+ executable (native) x86-64, for MS Windows iron.cat: data Iron.inf: Windows setup INFormation Ironx64.sys: PE32+ executable (native) x86-64, for MS Windows isolate.ini: Little-endian UTF-16 Unicode text, with CRLF line terminators srtsp64.cat: data srtsp64.inf: Windows setup INFormation srtsp64.sys: PE32+ executable (native) x86-64, for MS Windows srtspx64.cat: data srtspx64.inf: Windows setup INFormation srtspx64.sys: PE32+ executable (native) x86-64, for MS Windows SymDS64.cat: data SymDS64.sys: PE32+ executable (native) x86-64, for MS Windows SymDS.inf: Windows setup INFormation SymEFA64.cat: data SymEFA64.sys: PE32+ executable (native) x86-64, for MS Windows SymEFA.inf: Windows setup INFormation symnet64.cat: data SymNet.inf: Windows setup INFormation symnetv64.cat: data SymNetV.inf: Windows setup INFormation symtdiv.sys: PE32+ executable (native) x86-64, for MS Windows --- snip --- Trace log: --- snip --- $ WINEDEBUG=+seh,+relay,+loaddll,+ntoskrnl,+ntdll,+server,+service wineboot >>log.txt 2>&1 ... 003c:trace:service:load_service_config Image path = L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys" 003c:trace:service:load_service_config Group = (null) ... 003c:trace:service:load_service_config Service account name = L"LocalSystem" ... 003c:trace:service:load_service_config Display name = L"Symantec Hash Provider" 003c:trace:service:load_service_config Service dependencies : (none) 003c:trace:service:load_service_config Group dependencies : (none) ... 003c:Call KERNEL32.ExpandEnvironmentStringsW(0003b9d0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",000439c0,0000003c) ret=1400062de 003c:Call kernelbase.ExpandEnvironmentStringsW(0003b9d0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",000439c0,0000003c) ret=7bc4429f 003c:Call ntdll.RtlInitUnicodeString(0021f628,0003b9d0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys") ret=7b042c06 003c:Ret ntdll.RtlInitUnicodeString() retval=00000078 ret=7b042c06 003c:Call ntdll.RtlExpandEnvironmentStrings_U(00000000,0021f628,0021f618,0021f614) ret=7b042c47 003c:Ret ntdll.RtlExpandEnvironmentStrings_U() retval=00000000 ret=7b042c47 003c:Ret kernelbase.ExpandEnvironmentStringsW() retval=0000003c ret=7bc4429f 003c:Ret KERNEL32.ExpandEnvironmentStringsW() retval=0000003c ret=1400062de 003c:Call KERNEL32.GetBinaryTypeW(000439c0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",0021f7c0) ret=140006473 003c:Call kernelbase.CreateFileW(000439c0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",80000000,00000001,00000000,7fd700000003,00000000,00000000) ret=7b61b63d ... 003c:Call ntdll.RtlDosPathNameToNtPathName_U(000439c0 L"\\SystemRoot\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",0021f458,00000000,00000000) ret=7b0160a0 003c:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 ret=7b0160a0 003c:Call ntdll.NtCreateFile(0021f3e8,80100080,0021f428,0021f418,00000000,00000000,00000001,00000001,00000060,00000000,00000000) ret=7b01623a 003c:Ret ntdll.NtCreateFile() retval=c000003a ret=7b01623a 003c:Call ntdll.RtlNtStatusToDosError(c000003a) ret=7b01633c 003c:Ret ntdll.RtlNtStatusToDosError() retval=00000003 ret=7b01633c ... 003c:Ret kernelbase.CreateFileW() retval=ffffffffffffffff ret=7b61b63d 003c:Ret KERNEL32.GetBinaryTypeW() retval=00000000 ret=140006473 ... 0054:trace:ntoskrnl:load_driver loading driver L"C:\\windows\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys" ... 0054:Call KERNEL32.LoadLibraryW(0012d578 L"C:\\windows\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys") ret=0036490e 0054:Call kernelbase.LoadLibraryW(0012d578 L"C:\\windows\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys") ret=7bc3ab84 ... 0054:Call ntdll.LdrGetDllPath(0012d578 L"C:\\windows\\system32\\drivers\\NAVx64\\1100000.088\\ccHPx64.sys",00000000,00d5faf0,00d5fae8) ret=7b01bc26 0054:Ret ntdll.LdrGetDllPath() retval=00000000 ret=7b01bc26 ... 0054:Call ntdll.LdrLoadDll(0012d958 L"C:\\windows\\syswow64;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0",00000000,00d5fb10,00d5faf8) ret=7b01bdfc ... 0054: create_file( access=80100000, sharing=00000005, create=1, options=00000060, attrs=00000000, objattr={rootdir=0000,attributes=00000000,sd={},name=L""}, filename="/home/focht/projects/wine/mainline-install-x86_64/lib/wine/cchpx64.sys" ) ... 0054: create_file() = NO_SUCH_FILE { handle=0000 } ... 0054:Ret ntdll.LdrLoadDll() retval=c0000135 ret=7b01bdfc ... 0054:Ret kernelbase.LoadLibraryW() retval=00000000 ret=7bc3ab84 ... 0054:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\ccHP": c0000142 --- snip --- '\\SystemRoot\\system32\\drivers' is a valid path for REG_EXPAND_SZ type 'ImagePath' as well. It doesn't need to be '%SystemRoot%\\xxx'. Due to 'GetBinaryTypeW' failure, the "else" path is taken which uses 'WOW64' flag. All services created by 32-bit installer have 'WOW64' set by design, including the 64-bit services which leads to the incorrect "fallback" choice. Wine source: https://source.winehq.org/git/wine.git/blob/784cb2060ab63076adc349dcb1d15a6… --- snip --- 856 static DWORD get_winedevice_binary_path(struct service_entry *service_entry, WCHAR **path, BOOL *is_wow64) 857 { 858 static const WCHAR winedeviceW[] = {'\\','w','i','n','e','d','e','v','i','c','e','.','e','x','e',0}; 859 WCHAR system_dir[MAX_PATH]; 860 DWORD type; 861 862 if (!is_win64) 863 *is_wow64 = FALSE; 864 else if (GetBinaryTypeW(*path, &type)) 865 *is_wow64 = (type == SCS_32BIT_BINARY); 866 else 867 *is_wow64 = service_entry->is_wow64; 868 869 GetSystemDirectoryW(system_dir, MAX_PATH); 870 HeapFree(GetProcessHeap(), 0, *path); 871 if (!(*path = HeapAlloc(GetProcessHeap(), 0, lstrlenW(system_dir) * sizeof(WCHAR) + sizeof(winedeviceW)))) 872 return ERROR_NOT_ENOUGH_SERVER_MEMORY; 873 874 lstrcpyW(*path, system_dir); 875 lstrcatW(*path, winedeviceW); 876 return ERROR_SUCCESS; 877 } --- snip --- Virustotal.com scan of the binary: https://www.virustotal.com/gui/file/b8110fba782df5f9bfc25d39315b5ccd1f375b2… $ sha1sum NAV10TBEN.exe eadfb9c860146186c548aba695a9be87607f5586 NAV10TBEN.exe $ du -sh NAV10TBEN.exe 74M NAV10TBEN.exe $ wine --version wine-6.0-rc4 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 2

[Bug 23583] New: Kaspersky Internet Security 2010 needs FLTMGR.SYS to install in Vista and Win 7 mode
by wine-bugs＠winehq.org 18 Jun '23

18 Jun '23

http://bugs.winehq.org/show_bug.cgi?id=23583 Summary: Kaspersky Internet Security 2010 needs FLTMGR.SYS to install in Vista and Win 7 mode Product: Wine Version: 1.2-rc7 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: bojan(a)antonovic.ch Created an attachment (id=29472) --> (http://bugs.winehq.org/attachment.cgi?id=29472) install log See summary and attachment. -- 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 25

[Bug 47728] New: Project Reality BF2 PRBF2.exe crashes on startup
by wine-bugs＠winehq.org 17 Jun '23

17 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=47728 Bug ID: 47728 Summary: Project Reality BF2 PRBF2.exe crashes on startup Product: Wine Version: 4.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs(a)winehq.org Reporter: apq49584(a)tuofs.com Distribution: --- Created attachment 65203 --> https://bugs.winehq.org/attachment.cgi?id=65203 backtrace for prbf2.exe Debian 10 buster with winehq packaged wine-devel and libfaudio from OBS. Download link: https://www.realitymod.com/downloads winecfg was used to set a virtual desktop of 1024x768. (The PRBF2.exe works fine when a native d3dx9_25.dll (sha256:4c54df27ce84d21b2924e64ff79b13e7876ce85d8e0c9c1d0abd8da73888187a) is placed in the game folder. This is just background information and was NOT done for the bug report.) This is my first bug report here, so if you need anything else, say it and i will provide. thanks -- 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 13

[Bug 53187] New: user32:menu - test_menu_input()'s tests 6, 8, 10, 12, 14,16 fail semi-systematically on Windows in Russian and Chinese and other locales
by WineHQ Bugzilla 15 Jun '23

15 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=53187 Bug ID: 53187 Summary: user32:menu - test_menu_input()'s tests 6, 8, 10, 12, 14,16 fail semi-systematically on Windows in Russian and Chinese and other locales 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:menu - test_menu_input()'s tests 6, 8, 10, 12, 14,16 fail semi-systematically on Windows in some locales: menu.c:2324: Test failed: test 6 menu.c:2324: Test failed: test 8 menu.c:2324: Test failed: test 10 menu.c:2324: Test failed: test 12 menu.c:2324: Test failed: test 14 menu.c:2324: Test failed: test 16 https://test.winehq.org/data/patterns.html#user32:menu The WineTest results shows: * Systematic failures in Russian (except on 2022-06-09!). * Systematic failures in Chinese but only since 2022-06-10 (up to the current date, 2022-06-17). * And a failure in Hebrew but only on 2022-04-27! None of the behavior changes corresponds to times when the locale snapshots were updated. A TestBot run shows the same systematic (2 out of 2) failures in Arabic, Hebrew, Hindi, Hindi+UTF-8 and Russian (so not in Chinese). -- 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 53877] New: vbscript compile_assignment assertion when assigning multidimensional array by indices
by WineHQ Bugzilla 15 Jun '23

15 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=53877 Bug ID: 53877 Summary: vbscript compile_assignment assertion when assigning multidimensional array by indices Product: Wine Version: 7.20 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: --- The following works in real vbscript: Dim x Redim x(10) x(1) = Array(5, 6, 7) WScript.echo x(1)(0) WScript.echo x(1)(2) x(1)(0) = x(1)(2) WScript.echo x(1)(0) Output: 5 7 7 When running through Wine vbscript an assertion happens when processing x(1)(0) = x(1)(2) case EXPR_CALL: call_expr = (call_expression_t*)left; assert(call_expr->call_expr->type == EXPR_MEMBER); Stepping through the debugger, call_expr->call_expr->type appears to be EXPR_CALL -- 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 2

[Bug 50859] New: X Error of failed request: GLXBadFBConfig
by WineHQ Bugzilla 14 Jun '23

14 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=50859 Bug ID: 50859 Summary: X Error of failed request: GLXBadFBConfig Product: Wine-staging Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: linsilstef(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- [stefan@yuntani Downloads]$ wine64 Gw2Setup-64.exe 0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1. 005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1 0024:fixme:heap:RtlSetHeapInformation 0000000000020000 0 000000000022FD30 4 0024:fixme:heap:RtlSetHeapInformation 0000000001620000 0 000000000022FD10 4 0024:fixme:heap:RtlSetHeapInformation 0000000001620000 1 0000000000000000 0 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFO X Error of failed request: GLXBadFBConfig Major opcode of failed request: 150 (GLX) Minor opcode of failed request: 0 () Serial number of failed request: 218 Current serial number in output stream: 218 The error also occurs in wine 6.3. and Wine 6.4 System Fedora 34 Mesa version 21.0.0-2 -- 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 27

[Bug 43708] New: Major terrain glitching on SPORE
by wine-bugs＠winehq.org 14 Jun '23

14 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=43708 Bug ID: 43708 Summary: Major terrain glitching on SPORE Product: Wine-staging Version: 2.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: emily.shadowsong(a)gmail.com CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- Created attachment 59176 --> https://bugs.winehq.org/attachment.cgi?id=59176 Clearly, it's already getting wierd... I've been playing SPORE for a while now, it has worked normally; at one point in playing I pressed ALT+TAB and the whole terrain just glitched. It shows up that way on the map, it's not graphics-related because I can physically touch the messed-up land. There's sometimes jagged spikes, often times lines through the planet, and extremely tall mountains, making the game practically unplayable unless I have wings. Sometimes it'll appear as though my nest spawned inside water, and if I try to walk out of the water and onto what looks like land I'll be eaten by the fish monster. I've reinstalled SPORE about five times now and it hasn't helped. I've tried running SPORE on safe mode as well. I have the core SPORE, galactic adventures, and creepy & cute parts pack. Every time I alt tab, the terrain changes again and gets more and more messed up. -- 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 23

[Bug 49588] New: Cannot build wine with GCC 10 and Address Sanitizer
by WineHQ Bugzilla 13 Jun '23

13 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=49588 Bug ID: 49588 Summary: Cannot build wine with GCC 10 and Address Sanitizer Product: Wine Version: 5.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal(a)protonmail.com Distribution: --- Created attachment 67745 --> https://bugs.winehq.org/attachment.cgi?id=67745 config.log Hi, When I tried to compile Wine with address sanitizer with GCC 10 with this command ``` ./configure --enable-win64 CFLAGS="-Og -fsanitize=address" LDFLAGS="-fsanitize=address -lasan -lpthread" make -j8 ``` then this errors prints to config.log when configuring build ``` configure:4663: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:4663: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. ``` -- 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 47193] New: Sony Vegas PRO 16 reports successful installation but there are no files installed
by wine-bugs＠winehq.org 13 Jun '23

13 Jun '23

https://bugs.winehq.org/show_bug.cgi?id=47193 Bug ID: 47193 Summary: Sony Vegas PRO 16 reports successful installation but there are no files installed Product: Wine-staging Version: 4.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: donanykey(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 64442 --> https://bugs.winehq.org/attachment.cgi?id=64442 WINEDEBUG=+msi Hi Vegas PRO 16 trial installer reports successful installation but there are no files actually installed. P.s. All installation options unchecked other than Vegas PRO itself Best D -- 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 11

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