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.
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.
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.
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.
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.
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.
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.
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.
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.
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.