wine-bugs December 2020

wine-bugs@winehq.org

1 participants
7042 discussions

[Bug 50284] New: FSCTL_GET_REPARSE_POINT doesn't contain any target for a symbolic link
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50284 Bug ID: 50284 Summary: FSCTL_GET_REPARSE_POINT doesn't contain any target for a symbolic link Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 68841 --> https://bugs.winehq.org/attachment.cgi?id=68841 Test program https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b… does contain some support for reading relative symlinks, but it doesn't seem to work currently; the SubstituteNameLength and PrintNameLength fields of SymbolicLinkReparseBuffer are zero after a call to DeviceIoControl(FSCTL_GET_REPARSE_POINT), see the attached test program. -- 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 50303] New: MSI package installation fails in wine-staging
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50303 Bug ID: 50303 Summary: MSI package installation fails in wine-staging Product: Wine-staging Version: 6.0-rc1 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 68874 --> https://bugs.winehq.org/attachment.cgi?id=68874 terminal output during prefix creation (Wine-Mono fails to install) This may be related to bug #50036. The problem is present in Staging since https://github.com/wine-staging/wine-staging/commit/f9e86098b3136869479621e… For example when you create a new prefix, the Wine-Mono package fails to install. The same failure occurs when I try to install Nvidia Physx via winetricks. Works properly with the previous staging commit: https://github.com/wine-staging/wine-staging/commit/023588ac34c3314d18f4ebb… -- 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 50036] New: Remaining issues in Bugs in ntdll-Junction_Points in staging
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50036 Bug ID: 50036 Summary: Remaining issues in Bugs in ntdll-Junction_Points in staging Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 68477 --> https://bugs.winehq.org/attachment.cgi?id=68477 Test code for showing the issue With the ntdll-Junction_Points, there's a few remaining issues that are unimplemented: - When opening a symbolic link with CreateFile(), it doesn't take the FILE_FLAG_OPEN_REPARSE_POINT flag into account. E.g. if the symlink points at a nonexistent file, if the link is opened with CreateFile() with the FILE_FLAG_OPEN_REPARSE_POINT flag set, the operation should succeed (inspecting the link), but without the flag, it should fail (as the link points at a nonexistent file). Currently, it succeeds in both cases. - If inspecting the handle opened with CreateFile() with GetFileInformationByHandleEx(FileAttributeTagInfo), the ReparseTag field is left zero. This can be tested with the attached test app. On real windows, it prints something like this: CreateFile(FILE_FLAG_OPEN_REPARSE_POINT) = 0000000000000094 ReparseTag = a000000c CreateFile(0) = FFFFFFFFFFFFFFFF While on wine with the ntdll-Junction_Points patchset applied, it prints: CreateFile(FILE_FLAG_OPEN_REPARSE_POINT) = 000000000000003C ReparseTag = 0 CreateFile(0) = 000000000000003C ReparseTag = 0 -- 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 20

[Bug 50283] New: FILE_OPEN_REPARSE_POINT breaks error reporting for deletes of directories
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50283 Bug ID: 50283 Summary: FILE_OPEN_REPARSE_POINT breaks error reporting for deletes of directories Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 68840 --> https://bugs.winehq.org/attachment.cgi?id=68840 Test program In order to generically delete a file system entry, regardless of whether it is a regular file, symlink or directory, one can open a handle to it and delete it with a call to SetFileInformationByHandle(FileDispositionInfo). By opening the handle with FILE_FLAG_OPEN_REPARSE_POINT, a potential symlink gets handled by removing the symlink itself, not the target file it points to. If a handle opened with the FILE_FLAG_OPEN_REPARSE_POINT flag set turns out to be a directory, error reporting for the SetFileInformationByHandle call fails. This is caused by [1] in combination with [2]. These two cases make O_SYMLINK, which includes O_PATH, be added when opening the file descriptor which turns out to be a directory. The O_PATH flag causes the later fdopendir() and readdir() to not return anything, causing is_dir_empty [3] to indicate that the directory is empty and removal will succeed, even though it doesn't. This triggers errors in a std::filesystem testcase in libc++ [4], when checking to make sure that attempts to remove a non-empty directory properly signals errors. [1] https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b… [2] https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b… [3] https://source.winehq.org/git/wine.git/blob/fac1e40aaf0726a3e328a922cb49692… [4] https://github.com/llvm/llvm-project/blob/1e260f955d3123351fc68de8c2dde02b1… The issue can be reproduced with the attached fairly minimal test program. -- 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 49782] New: Elite Dangerous Horizons: crashes with wine64 5.16
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=49782 Bug ID: 49782 Summary: Elite Dangerous Horizons: crashes with wine64 5.16 Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: klaus.heissler(a)tutanota.com Distribution: --- Created attachment 68098 --> https://bugs.winehq.org/attachment.cgi?id=68098 terminal output The launcher and game starts normally and gets all the way to the main menu where it tries to connect to game servers for ~10 seconds and crashes after that. Works normally when downgraded to wine64 5.15. Regression Testing: (This was done in the existing prefix as I had problems installing dotnet40 to a new one) 75e616d52b452d37cc93f492d47eba641f9741c1 is the first bad commit commit 75e616d52b452d37cc93f492d47eba641f9741c1 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Aug 27 11:41:36 2020 +0200 ntdll: Clear the syscall frame on return instead of popping the previous one. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/ntdll/unix/signal_arm.c | 23 +++++++------- dlls/ntdll/unix/signal_arm64.c | 38 ++++++++++------------- dlls/ntdll/unix/signal_i386.c | 48 +++++++++++++---------------- dlls/ntdll/unix/signal_x86_64.c | 63 +++++++++++++++++--------------------- tools/winebuild/import.c | 67 ++++++++++++++++++----------------------- 5 files changed, 105 insertions(+), 134 deletions(-) Operating System: Arch Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 Kernel Version: 5.8.5-arch1-1 OS Type: 64-bit Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31,4 GiB of RAM Graphics Processor: GeForce GTX 1070/PCIe/SSE2 // Nvidia proprietary 450.66-16 -- 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 26

[Bug 50141] New: PASCO Capstone: installed and worked until OS update (and wine update with it) and now shows error on boot
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50141 Bug ID: 50141 Summary: PASCO Capstone: installed and worked until OS update (and wine update with it) and now shows error on boot Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winkelnp04(a)gmail.com Distribution: --- Created attachment 68639 --> https://bugs.winehq.org/attachment.cgi?id=68639 Error File On Manjaro. PASCO Capstone (software required in my Physics course) installed and worked fine until November Manjaro update, with updated wine packages. Now it installed fine, but doesn't start. I tried installing it with older versions of wine, but 1.13+ give the same error now, and anything below starts the program, but shows no content (as if it couldnt load part of the code, since the menubar shows up) I know this seems like a Manjaro problem, but could it maybe also be a wine problem? sorry if i'm doing this wrong. -- 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 50081] New: Kate on Windows needs msvcp140_1.dll._Aligned_get_default_resource
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=50081 Bug ID: 50081 Summary: Kate on Windows needs msvcp140_1.dll._Aligned_get_default_resource Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- Created attachment 68536 --> https://bugs.winehq.org/attachment.cgi?id=68536 Logging in (KDE-) Konsole during start The windows version of the editor Kate crashes during startup. Looks like #49954. -- 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 49483] New: snapcamera crashes at start
by WineHQ Bugzilla 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=49483 Bug ID: 49483 Summary: snapcamera crashes at start Product: Wine Version: 5.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: animegirl(a)stronzi.org Distribution: --- Created attachment 67597 --> https://bugs.winehq.org/attachment.cgi?id=67597 crash log kUbuntu 20.04 -- 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 42707] New: World of Warships: Cannot display inventory and clan screens
by wine-bugs＠winehq.org 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=42707 Bug ID: 42707 Summary: World of Warships: Cannot display inventory and clan screens Product: Wine Version: 2.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Andreas.Schallenberg(a)Eurobild.com Distribution: --- Created attachment 57682 --> https://bugs.winehq.org/attachment.cgi?id=57682 Backtrace when opening clan screen WoWS cannot enter Inventory screen or clan screen. When trying, it opens up a semi-transparent layer with a anchor-symbol with an animation. This step happens on Windows as well to indicate the loading. Under wine there is no further progress. In the better case, the screen stays as is forever. In the worse case (happens most often with inventory) there is a stack backtrace being displayed. In both cases the user can proceed by closing the semi-transparent layer. Environment: - World of Warships v0.6.2.2 (issue is the same with older versions) - Wine 2.4 (downloaded from http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_Leap_42.…) - Linux jordan 4.4.49-16-default #1 SMP Sun Feb 19 17:40:35 UTC 2017 (70e9954) x86_64 x86_64 x86_64 GNU/Linux -- 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 22

[Bug 39472] New: World of Warships 0.4.x/0.5.x client runs out of GL memory after many consecutive games
by wine-bugs＠winehq.org 13 Feb '21

13 Feb '21

https://bugs.winehq.org/show_bug.cgi?id=39472 Bug ID: 39472 Summary: World of Warships 0.4.x/0.5.x client runs out of GL memory after many consecutive games Product: Wine Version: 1.7.53 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, by having a large number of consecutive games within same session, the client will eventually run out of GL memory. Not sure if this is a Wine bug or a bug in the game engine itself. It doesn't matter if ARB or GLSL shader backend (default), CSMT or non-CSMT (default) is used. Plain Wine and Wine-Staging (for CSMT). The leak is around 50-70 MB per game so it takes 20-30 games until it becomes apparent. When that happens you get strange effects due to failing GL calls. Console output at the exact point: --- snip --- ... 0028:err:d3d_texture:texture2d_prepare_texture >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexImage2D @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/texture.c / 1000 0028:err:d3d_texture:wined3d_texture_bind >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glGenTextures @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/texture.c / 199 0028:err:d3d_texture:texture2d_prepare_texture >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexImage2D @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/texture.c / 1000 0028:err:d3d_surface:wined3d_surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/surface.c / 1732 0028:err:d3d_draw:draw_strided_fast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawArrays @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/drawprim.c / 91 005a:trace:seh:__regs_MSVCRT__setjmp3 buf=0x2cc5da20 ebx=351af2d0 esi=2f6c5150 edi=351af2a0 ebp=0ea7e928 esp=0ea7e914 eip=00d65da3 frame=0ea7ea48 0028:err:d3d_surface:surface_blt_fbo >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glReadBuffer() @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/surface.c / 1078 0028:err:d3d_draw:draw_strided_fast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawArrays @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/drawprim.c / 91 0028:err:d3d_texture:texture2d_prepare_texture >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexImage2D @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/texture.c / 1000 0028:err:d3d_shader:shader_arb_select >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, priv->current_fprogram_id); @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/arb_program_shader.c / 4692 0028:err:d3d_draw:draw_strided_fast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawArrays @ /home/focht/projects/wine/wine.repo/staging-src/dlls/wined3d-csmt/../wined3d/drawprim.c / 91 --- snip --- I continuously monitor the GPU memory usage using 'nvidia−smi' tool from another terminal: --- snip --- $ watch -n2 nvidia-smi ... Fri Oct 16 18:26:51 2015 +------------------------------------------------------+ | NVIDIA-SMI 352.41 Driver Version: 352.41 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GTX 850M Off | 0000:01:00.0 Off | N/A | | N/A 50C P8 N/A / N/A | 1385MiB / 2047MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 4151 G /usr/libexec/Xorg 49MiB | | 0 4485 G ...mes\World_of_Warships\worldofwarships.exe 1325MiB | +-----------------------------------------------------------------------------+ --- snip --- 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.

2 6

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 December 2020