wine-bugs March 2021

wine-bugs@winehq.org

1 participants
6125 discussions

[Bug 50892] New: WINE 6.3: opentrack-wrapper-wine segfaults with message "Got unexpected trap 14 during process initialization".
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50892 Bug ID: 50892 Summary: WINE 6.3: opentrack-wrapper-wine segfaults with message "Got unexpected trap 14 during process initialization". Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xeno(a)x-s.com.pl Distribution: --- As per Summary opentrack-wrapper-wine.exe.so process (opentrack trackir and freetrack protocols wrapper) crashes just after launch. If started from console with env WINEPREFIX=<my_wine_prefix_path> wine /usr/lib64/opentrack/opentrack-wrapper-wine.exe.so it crashes spitting out message: 00fc:err:seh:segv_handler_early Got unexpected trap 14 during process initialization Once wine is downgraded to 5.x (here tested with 5.18 and 5.22) wrapper process starts just fine and stays on until headtracking is stopped. Tested with opentrack 2.3.12 and 2.3.13, wine 6.3. Steps to reproduce: start opentrack select pointtracker as input, accela as filter wine as output configure wine output plugin and point it to wine prefix where app that uses headtracking is installed start headtracking start app/game from Expected result: - opentrack-wrapper-wine.exe.so stays in the list of active processes - headtracking works in games/apps running in wine. Actual results: - opentrack-wrapper-wine.exe.so process appears for a brief moment then instantly closes - headtracking works in opentrack preview window but not in a apps running in wine. OpenTrack is fa opensource project obtainable from github: https://github.com/opentrack/opentrack I can provide rough but working Fedora x86_64 rpm if needed. -- 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 48486] New: cmd WCMD_ReadAndParseLine contains non-null terminated strings, causing garbage output in trace logs
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=48486 Bug ID: 48486 Summary: cmd WCMD_ReadAndParseLine contains non-null terminated strings, causing garbage output in trace logs Product: Wine Version: 5.0-rc6 Hardware: x86 OS: Linux Status: NEW Severity: trivial Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. It's already PE but various strings have not been converted yet. The function in the summary is the one most offending/annoying in trace logs. There are other occurrences as well. Example download: https://github.com/git-for-windows/git/releases/download/v2.25.0.windows.1/… --- snip --- ... 006a:Call KERNEL32.MultiByteToWideChar(000001b5,00000000,00bd7a78 "\t\t@IF NOT EXIST bin\\rebase.exe @(\n\t\t\t@IF NOT EXIST bin @MKDIR bin\n\t\t\t@COPY usr\\bin\\rebase.exe bin\\rebase.exe\n\t\t)\n\t\t@IF NOT EXIST bin\\msys-2.0.dll @(\n\t\t\t@COPY usr\\bin\\msys-2.0.dll bin\\msys-2.0.dll\n\t\t)\n\t\t(a)bin\\rebase.exe -b 0x64000000 usr\\bin\\msys-2.0.dll\n"...,00000021,00be5238,00002000) ret=00401a09 006a:Ret KERNEL32.MultiByteToWideChar() retval=00000021 ret=00401a09 006a:Call KERNEL32.HeapFree(00110000,00000000,00bd7a78) ret=00401a22 006a:Ret KERNEL32.HeapFree() retval=00000001 ret=00401a22 006a:Call msvcrt.wcschr(00be523c L"@IF NOT EXIST bin\\rebase.exe @(",00000025) ret=004137f3 006a:Ret msvcrt.wcschr() retval=00000000 ret=004137f3 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000003,0041b706 L"remforifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000003) ret=00411489 006a:Ret KERNEL32.CompareStringW() retval=00000001 ret=00411489 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000003,0041b70c L"forifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000003) ret=004115c0 006a:Ret KERNEL32.CompareStringW() retval=00000003 ret=004115c0 006a:Call KERNEL32.CompareStringW(00000400,00001001,00be523e L"IF NOT EXIST bin\\rebase.exe @(",00000002,0041b712 L"ifelse\4357\444d\525f\6165\4164\646e\6150\7372\4c65\6e69e\6f4e\6320\6d6f\616d\646e\6e20\726f\6820\6e61\6c64\2065\7573\7070\696c\6465\necho.echo:echo/\764f\7265\6c66\776f\6420\7465\6365\6574\2064\6e69\6320\6d6f\616d\646e\ndo/I",00000002) ret=004115fa 006a:Ret KERNEL32.CompareStringW() retval=00000002 ret=004115fa ... --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/02f3a133b64ed1f979309e1399738ea… $ sha1sum Git-2.25.0-32-bit.exe 7dc64019c089d4a9a3700ee7140a7af9a5416199 Git-2.25.0-32-bit.exe $ du -sh Git-2.25.0-32-bit.exe 45M Git-2.25.0-32-bit.exe $ wine --version wine-5.0-rc6 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 4

[Bug 50801] New: Wine Mono crashes on macOS
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50801 Bug ID: 50801 Summary: Wine Mono crashes on macOS Product: Wine Version: 6.4 Hardware: x86-64 OS: Mac OS X Status: NEW Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Running the csc.exe shipped with Wine Mono on macOS 11.2.1 crashes with: 0024:err:virtual:virtual_setup_exception stack overflow 1456 bytes in thread 0024 addr 0x7bc2bd61 stack 0x130a50 (0x130000-0x131000-0x230000) >From a +relay,+seh log, trimmed by thread: 0024:Call msvcrt.memcpy(0022dec0,02950f35,00000010) ret=1801013e1 0024:Ret msvcrt.memcpy() retval=0022dec0 ret=1801013e1 0024:trace:seh:dispatch_exception code=c0000005 flags=0 addr=0000000002951170 ip=0000000002951170 tid=0024 0024:trace:seh:dispatch_exception info[0]=0000000000000001 0034:Call KERNEL32.HeapFree(00020000,00000000,000b96f0) ret=68765c83 0024:trace:seh:dispatch_exception info[1]=0000000000000498 0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0024:trace:seh:dispatch_exception rax=0000000000000498 rbx=0000000000000000 rcx=0000000000000001 rdx=0000000000000010 0024:trace:seh:dispatch_exception rsi=0000000000000010 rdi=0000000000a24dd0 rbp=000000000022e2c0 rsp=000000000022e270 0024:trace:seh:dispatch_exception r8=000000000022e5f0 r9=0000000002950f00 r10=000000000000000a r11=0000000002950f64 0024:trace:seh:dispatch_exception r12=0000000000a32e88 r13=000000000022e928 r14=000000000022e5f0 r15=0000000000000000 0024:trace:seh:call_vectored_handlers calling handler at 00000001801038F0 code=c0000005 flags=0 I haven't been able to get winedbg working well enough to give me any real information, but that memcpy call is from the end of mono_breakpoint_clean_code. I also got this from WINE_MONO_VERBOSE=1: Method (wrapper alloc) object object:AllocSmall (intptr,intptr) emitted at 0000000002951110 to 000000000295123b (code length 299) [csc.exe] So we're crashing on access to JIT-compiled code. There's probably a way to tell from the +seh log whether that's on execute access, but I'm just going to assume it is. -- 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 50415] New: MPC-HC 1.7.13 crashes when playing video (needs the EVR filter to support IEVRFilterConfig)
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50415 Bug ID: 50415 Summary: MPC-HC 1.7.13 crashes when playing video (needs the EVR filter to support IEVRFilterConfig) Product: Wine Version: 6.0-rc4 Hardware: x86-64 URL: https://github.com/mpc-hc/mpc-hc/releases/tag/1.7.13 OS: Linux Status: NEW Keywords: download, patch, source Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Distribution: --- Created attachment 69035 --> https://bugs.winehq.org/attachment.cgi?id=69035 evr: Stub IEVRFilterConfig. The attached patch helps; it falls back to the VMR. Continued from bug 45096. -- 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 44755] New: reg.exe: does not provide /reg: 64 switch in 64-bit wineprefix
by wine-bugs＠winehq.org 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=44755 Bug ID: 44755 Summary: reg.exe: does not provide /reg:64 switch in 64-bit wineprefix Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: registry Assignee: wine-bugs(a)winehq.org Reporter: wine(a)marco-rebhan.de Distribution: --- In a 64-bit prefix, the reg.exe command line switches /reg:32 and /reg:64 should be available to enable/disable registry redirection. A command like `wine reg import /reg:64 test.reg` should be perfectly valid, to prevent the imported keys from going somewhere in Wow6432Node, but instead it gives the following error: reg: Invalid syntax. Type "REG IMPORT /?" for help. As far as I could figure out, there is no workaround other than manually importing the keys in the regedit GUI (calling regedit from the command line with the registry file as an argument doesn't work), which makes importing keys correctly not automatable. Using wine-3.4 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.

2 11

[Bug 28995] New: Unable to use named pipes with ">" character in the name
by wine-bugs＠winehq.org 23 Apr '21

23 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=28995 Bug #: 28995 Summary: Unable to use named pipes with ">" character in the name Product: Wine Version: 1.3.32 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: valentyn.pavliuchenko(a)gmail.com Classification: Unclassified I have an app (Avid VENUE software) that uses pipes to work. The app fails to launch because of pipe name contains a character ">". MSDN says: The pipename part of the name can include any character other than a backslash, including numbers and special characters. The entire pipe name string can be up to 256 characters long. Pipe names are not case sensitive. App logs show the following: 23.957 CreateFile error '\\.\PIPE\D-Show Pipe GUI->DM': Invalid name. Changing ">" to "_" by direct editing executable files makes problem disappear. -- 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 18

[Bug 17823] New: A crash when installing Rhino 4.0 trial version
by wine-bugs＠winehq.org 23 Apr '21

23 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=17823 Summary: A crash when installing Rhino 4.0 trial version Product: Wine Version: 1.1.17 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P3 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrej(a)podzimek.org Created an attachment (id=20083) --> (http://bugs.winehq.org/attachment.cgi?id=20083) Output from the installer When installing a trial version of Rhino 4.0 obtained from here http://download.rhino3d.com/eval/?p=25, the installer reports successful completion. However, the terminal output shows a crash. Presumably, Rhino crashes when run after the installation. A small part of the GUI is displayed, but remains unresponsive. A dialog window for error-reporting pops up. -- 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 44

[Bug 50898] New: Improve performance for RGB lookups into color tables conversion
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50898 Bug ID: 50898 Summary: Improve performance for RGB lookups into color tables conversion Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: gabrielopcode(a)gmail.com Distribution: --- Created attachment 69710 --> https://bugs.winehq.org/attachment.cgi?id=69710 Generate a lookup cache for RGB into color table conversion This improves the performance of color conversion from RGB to palette significantly by generating a lookup cache for 5-bit-per-color RGB values (centered) into the palette, before doing the conversion, for older applications and games. The comments in the patch should describe the algorithm I came up with for large color tables. Note that Windows also quantizes the lookup to 5-bit-per-color already, so it very likely does something similar (but seems to do more caching based on my tests); we have this quantization in wine's code to match Windows, but we don't take advantage of it, so it's wasted. Generating it by looking through the color table for each entry in the lookup cache wouldn't be a good idea if the color table is large. The lookup cache itself is 32768 entries, which turns out to be the equivalent of a 256x128 image. The current algorithm used by wine works like that already: it goes through each pixel in the image, and for each pixel, it looks up every color in the color table, which is extremely slow. Generating the cache like that would mean images have to be at least 256x128 for it to have any benefit, otherwise it would be a performance regression instead, and that's not very reasonable to expect of older applications, and it wouldn't provide much. So, the table generation algorithm is much more efficient than that for large amount of colors in the table. In my synthetic tests generating 4096 tables with various color tables of 256 colors, it turned out to be at least 4x faster, sometimes even 4.5x depending on color table (even a purely random color table), for example a random table taking about 14406ms instead of 62056ms on my CPU. In fact, the algorithm is not far from being constant in terms of amount of colors in the table, taking only 50% more time from 16 colors to 256. So basically increasing the amount of colors from 16 to 256 doesn't make that much difference, since each color usually fills its own part of the lookup cache, which is not filled again (unless distance is shorter due to quantization, but that's only for one generation anyway). In contrast, going through each color in the table for each entry (the original algorithm) would massively increase the amount of time spent (from less than 10 seconds, up to more than a minute, or 6x slower). For a few benchmark examples: a 256-color table with the algorithm takes about 14000ms to do 4096 iterations on my CPU, a 40-color table takes about 12000ms, so it's only 17% slower with this algorithm. The 40 colors seems to be the cutoff on my CPU where the algorithms start to differ in performance, with the straight one being faster at lower amount of colors, presumably due to better cache locality and branch prediction. A fast and easy way to "see this in action" is to download Winamp, then launch it and right-click on the top, click on the "Nullsoft Winamp..." menu item and then go to the Credits tab. Depending on your CPU you can clearly see the FPS difference and/or CPU usage for one core. (Note that it still has some fps drops, this is normal and happens on Windows as well, even when the CPU core is not maxed out, it's inherent in the app) http://web.archive.org/web/20180902190237/http://winamparchive.org/dl/winam… Further improvements would require caching it somehow between calls, but I believe that requires either more fragile changes to gdi32 code, or semi-hacks to deal with a typical applications' expectations, so this should be a good start for now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 25265] New: Foobar2000 won't watch folders
by wine-bugs＠winehq.org 23 Apr '21

23 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=25265 Summary: Foobar2000 won't watch folders Product: Wine Version: 1.3.7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lucisandor(a)gmail.com Foobar2000 is a media player with an automatically updated media library. The library updates correctly when updates are triggered manually, but, under Wine, it does not detect changes in folders. Moreover, Foobar2000 provides for such cases a "polling" function, but that is useless too. The most upsetting is that changes in watched folders are not detected even when they were produced by Fooobar2000, e.g., by using the menu option "move file". If I move a file from one watched folder to another, the media library will not be aware of the changes in any of the two locations. -- 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 19

[Bug 50894] New: Starting rundll32.exe via sysnative fails
by WineHQ Bugzilla 23 Apr '21

23 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50894 Bug ID: 50894 Summary: Starting rundll32.exe via sysnative fails Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: rpisl(a)seznam.cz Distribution: --- Starting rundll32 via c:\windows\sysnative\rundll32.exe is broken since Wine 6.5. It worked up to Wine 6.4. wine cmd c:\>cd c:\windows\sysnative c:\windows\sysnative>dir ... files listed properly c:\windows\sysnative>rundll32.exe wine: failed to open L"c:\\windows\\sysnative\\rundll32.exe": c0000135 Can't recognize 'rundll32.exe' as an internal or external command, or batch script. Creating unix symlink from sysnative to system32 in wine prefix is a workaround. -- 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

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 2021