October 2023 - Wine-bugs - list.winehq.org

[Bug 55764] New: Wine will temporarily disconnect logitech devices for a split second when launching game/application.
by WineHQ Bugzilla 29 Nov '23

29 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=55764 Bug ID: 55764 Summary: Wine will temporarily disconnect logitech devices for a split second when launching game/application. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: noltogreen2187(a)gmail.com Distribution: --- Created attachment 75253 --> https://bugs.winehq.org/attachment.cgi?id=75253 dmesg logs after launching game. (Note: currently only using logitech g pro gaming keyboard) Steps to reproduce: 1. Get a logitech mouse or keyboard (in my case logitech g pro gaming keyboard, and logitech g203 mouse). 2. Launch game/application. And then you wont be able to input keystrokes for a split second. This bug is really annoying since i use input-remapper to well, remap inputs, so when this happens my set profile stops and ill have to go re-apply it everytime i want to play a game. It will also make the time that it freezes alot longer. This doesnt happen with steam or using wine in a flatpak. Wine version doesnt seem to matter, maybe if i use a version from a year or two back it wont happen, but idk i havent tested. My motherboard & bios version: Gigabyte Technology Co., Ltd. B450M DS3H-CF, F41. -- 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 10

[Bug 53556] New: winealsa.drv segfaults on process exit
by WineHQ Bugzilla 28 Nov '23

28 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=53556 Bug ID: 53556 Summary: winealsa.drv segfaults on process exit Product: Wine Version: 7.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: brendan(a)redmandi.com Distribution: --- Created attachment 72919 --> https://bugs.winehq.org/attachment.cgi?id=72919 Adds test to kernelbase_test.exe sync I get a segfault on process exit whenever the winealsa.drv is loaded. I can recreate this by running the winmm_test.exe midi test for example. I've also attached a patch that adds a test to kernelbase_test.exe (under the 'sync' tests) that recreates this issue. It's recreated in this patch without the process exit (thread termination is enough). Here's the stacktrace for the winealsa.drv thread at the beginning of signal_exit_thread (not long after SIGQUIT is signaled): #0 0x00007ffff7cee3ce in signal_exit_thread () #1 0x00007ffff7d0d25b in abort_thread (status=status(a)entry=0) at ../../include/winnt.h:2246 #2 0x00007ffff7cf12e8 in quit_handler (signal=<optimised out>, siginfo=<optimised out>, ucontext=<optimised out>) at ../../dlls/ntdll/unix/signal_x86_64.c:2861 #3 <signal handler called> #4 0x00007ffff7e0a195 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7ffff5aa2528 <notify_read_cond+40>) at ./nptl/futex-internal.c:57 #5 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7ffff5aa2528 <notify_read_cond+40>) at ./nptl/futex-internal.c:87 #6 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word(a)entry=0x7ffff5aa2528 <notify_read_cond+40>, expected=expected(a)entry=0, clockid=clockid(a)entry=0, abstime=abstime(a)entry=0x0, private=private(a)entry=0) at ./nptl/futex-internal.c:139 #7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at ./nptl/pthread_cond_wait.c:503 #8 ___pthread_cond_wait (cond=cond(a)entry=0x7ffff5aa2500 <notify_read_cond>, mutex=mutex(a)entry=0x7ffff5aa2540 <notify_mutex>) at ./nptl/pthread_cond_wait.c:627 #9 0x00007ffff5a99a67 in midi_notify_wait (args=0x23cfdd0) at ../../dlls/winealsa.drv/alsamidi.c:1512 #10 0x00007ffff7cd7f13 in __wine_unix_call (handle=<optimised out>, code=<optimised out>, args=0x7ffff5aa2528 <notify_read_cond+40>) at ../../dlls/ntdll/unix/loader.c:1362 #11 0x00007ffff7cee565 in __wine_syscall_dispatcher () #12 0x00000000024cf640 in ?? () #13 0x0000000000000019 in ?? () #14 0x00007ffff7e0d850 in ?? () at ./nptl/pthread_create.c:321 #15 0x00007ffff7cee3cc in signal_start_thread () #16 0x0000000000000000 in ?? () Before the call to __GI___futex_abstimed_wait_cancelable64 (made from frame 7), the following line of code is executed: https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_cond_wait.c;h… __pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer); This appears to push some cleanup code on to a cleanup stack that glibc later attempts to use during thread termination. However, the buffer and cbuffer structs are allocated on the threads stack. Exploring frame 7, we can get the memory address for the buffer struct (0x24ce870): (gdb) f 7 #7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at ./nptl/pthread_cond_wait.c:503 warning: Source file is more recent than executable. 503 err = __futex_abstimed_wait_cancelable64 ( (gdb) p &buffer $1 = (struct _pthread_cleanup_buffer *) 0x24ce870 I then step forward 4 instructions: (gdb) si 0x00007ffff7cee3d5 in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3d5 <signal_exit_thread+9>: test %rcx,%rcx (gdb) 0x00007ffff7cee3d8 in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3d8 <signal_exit_thread+12>: jne 0x7ffff7cee3dc <signal_exit_thread+16> (gdb) 0x00007ffff7cee3dc in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3dc <signal_exit_thread+16>: mov %rcx,%rsp (gdb) 0x00007ffff7cee3df in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3df <signal_exit_thread+19>: call *%rsi (gdb) bt #0 0x00007ffff7cee3df in signal_exit_thread () #1 0x00007ffff7d0a1f0 in start_thread (teb=0x67fd0000) at ../../dlls/ntdll/unix/thread.c:1070 #2 0x00007ffff7e0db43 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #3 0x00007ffff7e9fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) p $rsp $2 = (void *) 0x24cee00 And now the $rsp register is updated (to 0x24cee00), but it's to the right of the buffer struct. 0x24cee00 - 0x24ce870 = 0x590 (1424 bytes). So once the stack expands 1424 bytes (to the left), this buffer struct is overwritten. I add a watch to the buffer structs memory address and continue: (gdb) watch ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine (gdb) c Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff7e0c7a0 <__condvar_cleanup_waiting> New value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop> 0x00007ffff7fc2426 in __GI__dl_find_object (pc1=0x7ffff51663e9 <_Unwind_ForcedUnwind+57>, result=0x24ce8d0) at ./elf/dl-find_object.c:363 363 if (__glibc_unlikely (_dlfo_main.map_end == 0)) 1: x/i $rip => 0x7ffff7fc2426 <__GI__dl_find_object+6>: push %r13 (gdb) Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop> New value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57> 0x00007ffff5166c91 in get_cie_encoding (cie=0x7ffff516a1b8) at ../../../src/libgcc/unwind-dw2-fde.c:299 299 aug = cie->augmentation; 1: x/i $rip => 0x7ffff5166c91 <get_cie_encoding+1>: mov %rdi,%rbp (gdb) Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57> New value = (void (*)(void *)) 0x24ce890 0x00007ffff516584c in uw_update_context_1 (context=0x24ceb90, fs=0x24ce9d0) at ../../../src/libgcc/unwind-dw2.c:1454 1454 switch (fs->regs.reg[i].how) 1: x/i $rip => 0x7ffff516584c <uw_update_context_1+492>: lea 0x4209(%rip),%rbp # 0x7ffff5169a5c (gdb) c Continuing. It actually gets updated a few times, but the last update is to an invalid executable address (0x24ce890); which ultimately leads to the segfault: Thread 2 "winmm_test.exe" received signal SIGSEGV, Segmentation fault. 0x00000000024ce890 in ?? () 1: x/i $rip => 0x24ce890: rex.WXB add %al,(%r8) 1: x/i $rip => 0x24ce890: rex.WXB add %al,(%r8) -- 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 54359] New: DaciaMediaNavEvolutionToolbox crashes due to error in libcef
by WineHQ Bugzilla 28 Nov '23

28 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=54359 Bug ID: 54359 Summary: DaciaMediaNavEvolutionToolbox crashes due to error in libcef Product: Wine Version: 8.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dani.faugiana(a)gmail.com Distribution: --- Created attachment 73931 --> https://bugs.winehq.org/attachment.cgi?id=73931 Backtrace of the crash in libcef.dll Hello, I am trying to run DaciaMediaNavEvolutionToolbox to update the car maps. The application crashes right after starting, I have attached the backtrace. I have tried running the software in Windows XP and Windows 7 modes. Same result in both modes. The error seems to be in libcef.dll, the Chromium Embedded Framework. Searching other bugs, it seems that it's a bug that re-appears from time to time as Chromium changes its internals. Is the fix already ongoing? Or should I give up (or maybe try to help fixing it?) 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.

1 8

[Bug 55755] New: ntdll:wow64 - The 32-bit test_modules() fails to find the main module in Wine's new WoW mode
by WineHQ Bugzilla 28 Nov '23

28 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=55755 Bug ID: 55755 Summary: ntdll:wow64 - The 32-bit test_modules() fails to find the main module in Wine's new WoW mode Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ntdll:wow64 - The 32-bit test_modules() fails to find the main module in Wine's new WoW mode: wow64.c:1568: Test failed: main module not found See https://test.winehq.org/data/patterns.html#ntdll:wow64 In particular one can see this issue on fg-deb64-i386, fgtb-debian11-i386, fgtb-debian12-i386 and rbernon-*-wow64 which all run the 32-bit tests in the new Windows-on-Windows Wine mode. This failure does no happen in the 64-bit test, or when running in a pure 32-bit environment or in the old Windows-on-Windows mode. This also happens on macOS when running the 32-bit tests in the new WoW mode (see mac_rbernon-macos-*-wow64). A bisect shows that this failure started with the commit below: commit de81e2ea41b27a14f88177639c5b5d35a210b5bd Author: Alexandre Julliard <julliard(a)winehq.org> AuthorDate: Fri Oct 6 15:08:02 2023 +0200 ntdll: Only create the main module on the 32-bit side for wow64. This means this most likely has the same fix as bug 55744. -- 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 33208] New: WWII Battle Tanks: T-34 vs. Tiger selection of the new company causes to crash
by wine-bugs＠winehq.org 27 Nov '23

27 Nov '23

http://bugs.winehq.org/show_bug.cgi?id=33208 Bug #: 33208 Summary: WWII Battle Tanks: T-34 vs. Tiger selection of the new company causes to crash Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrey.goosev(a)gmail.com CC: andrey.goosev(a)gmail.com Classification: Unclassified Created attachment 43931 --> http://bugs.winehq.org/attachment.cgi?id=43931 logout + backtrace Game runs without any overrides, but has crash when selecting a new company. -- 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 6

[Bug 40183] New: unable to install GOTO bridge software
by wine-bugs＠winehq.org 27 Nov '23

27 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=40183 Bug ID: 40183 Summary: unable to install GOTO bridge software Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ajax_lusinchi(a)yahoo.fr Distribution: --- Created attachment 53690 --> https://bugs.winehq.org/attachment.cgi?id=53690 report from installation under ubuntu 140.04 with wine 1.6 GOTO bridge XVI works with windows Installation failed I also use without problem Funbridge sofware from the same firm -- 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 4

[Bug 53951] New: Corsairs game crashes at startup
by WineHQ Bugzilla 27 Nov '23

27 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=53951 Bug ID: 53951 Summary: Corsairs game crashes at startup Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: varrok(a)gmail.com Distribution: --- Created attachment 73527 --> https://bugs.winehq.org/attachment.cgi?id=73527 Logs from a clean wine32 prefix + winetricks dsound, quartz, gdi+, cinepack components. WinXp compatibility mode. Hi ????, I'm trying to get the Corsairs Gold game to run https://www.gog.com/game/corsairs_gold , but it refuses to. I got it to run on one prefix (with issues, but at least got through the intro videos, menus [with error messages] to gameplay), but reproducing it cleanly was too hard after multiple attempts. Sadly, this game doesn't have a demo for easy reproduction. When I launch the game (getting past the separate .exe launcher), black screen is displayed (where the cutscenes are supposed to play) for some time (probably video duration) then the game's splash image is displayed, and the game crashes at the first frame of the main menu. The report issue Wine popup appears, but doesn't manage to fill in the data to send even after waiting for a long while. I do have output logs though, attached here. Extra information: - This game uses cinepack codec for the .avi videos, but installing it via winetricks doesn't make them immediately run (they display black screen) - The game requires at least the quartz component of winetricks (or equivalent), and most likely dsound too - installing them alone didn't make the game get to the menu correctly. Tried various other including: directmusic, directshow, avifil32, dsmo, mf, allcodecs, gdi+, didn't seem to change anything. - The GOG version of the game uses a modified ddraw.dll (adraw.dll), it might be the cause of some issues. Some person posted a modified exe that is compatible with normal ddraw.dll https://sourceforge.net/p/dxwnd/discussion/general/thread/2a942442/#7aa5 (Not that I wish you to run potentially untrusted executables, so I'll just say I tried it and though the file seems a legit game executable, it didn't help this time) - The crashed game doesn't exit cleanly, and sometimes the next launch crashes a bit sooner than the others. Just a heads-up so you don't become insane from seeing different outcomes to seemingly the same action :) - wine-7.21-219-g5d1820c40bd , but the issue wasn't introduced in any new version - tested on a 32bit prefix, with emulated desktop 800x600 Br -- 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 13

[Bug 55689] New: rpcrt4:rpc - test_RpcServerInqDefaultPrincName() fails on macOS
by WineHQ Bugzilla 27 Nov '23

27 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=55689 Bug ID: 55689 Summary: rpcrt4:rpc - test_RpcServerInqDefaultPrincName() fails on macOS Product: Wine Version: unspecified Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com rpcrt4:rpc - test_RpcServerInqDefaultPrincName() fails on macOS: rpc.c:938: Test failed: got 1747 rpc.c:948: Test failed: got 1747 rpc.c:272: Test failed: RpcBindingSetAuthInfo failed (1747) rpc.c:280: Test failed: RpcBindingInqAuthInfo failed (1746) rpc.c:281: Test failed: expected NULL identity, got 00000000DEADBEEF rpc.c:282: Test failed: expected valid principal, got 00000000DEADBEEF rpc.c:283: Test failed: expected RPC_C_AUTHN_LEVEL_PKT_PRIVACY, got 0 rpc.c:284: Test failed: expected RPC_C_AUTHN_WINNT, got 0 See https://test.winehq.org/data/patterns.html#rpcrt4:rpc This set of failures first appeared on 2023-09-29. However they may have been hidden by the crash that was happening up until 2023-09-27 so having these failures is probably progress. -- 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 55690] New: winhttp:winhttp - test_large_data_authentication() gets an HTTP denied error on macOS
by WineHQ Bugzilla 27 Nov '23

27 Nov '23

https://bugs.winehq.org/show_bug.cgi?id=55690 Bug ID: 55690 Summary: winhttp:winhttp - test_large_data_authentication() gets an HTTP denied error on macOS Product: Wine Version: unspecified Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com winhttp:winhttp - test_large_data_authentication() gets an HTTP denied error on macOS: winhttp.c:3019: Test failed: got 401 See https://test.winehq.org/data/patterns.html#winhttp:winhttp Where 401 == HTTP_STATUS_DENIED This failure first appeared on 2023-09-29. However it may have been hidden by the crash that was happening up until 2023-09-27 so having this failure is probably progress. -- 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 34998] New: 11 button mouse not detected in Wow
by wine-bugs＠winehq.org 26 Nov '23

26 Nov '23

http://bugs.winehq.org/show_bug.cgi?id=34998 Bug #: 34998 Summary: 11 button mouse not detected in Wow Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: info(a)nuteknik.com Classification: Unclassified I am running wine 1.7.6 on Ubuntu 13.10. I have a Razer Ochori 2013 mouse whose mouse buttons are not all detected while running wow 5.4. The mouse has four side buttons, two on the left, two on the right. Both buttons on the right side are not detected in wow. xev receives Buttonpress events for those two buttons, as 10 and 11. note: xev receives both left side buttons as 8 and 9. And curiously...I have never been able find buttons 6 or 7 on this mouse. The mouse wheel does not tilt right or left... I posted this issue in the forums and was suggested to open a bug. Thanks for your help. -- 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 3