https://bugs.winehq.org/show_bug.cgi?id=52189
Bug ID: 52189
Summary: Guitar Pro 7.5 crashes when DPI is set to anything but
96
Product: Wine
Version: 6.23
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: anarsoul(a)gmail.com
Distribution: ---
Guitar Pro 7.5 crashes very often in random places (when starting tab playback,
when opening new tab, when saving new tab) if DPI in winecfg is set to anything
but 96
--
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=51438
Bug ID: 51438
Summary: Rust compiler crashes with "free(): double free
detected in tcache 2" message
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mikrutrafal(a)protonmail.com
Distribution: ---
When I installed on clear prefix rustc with cargo -
https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi
```
wget https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi
msiexec /i rust-1.53.0-x86_64-pc-windows-gnu.msi
```
then after running commands
```
echo "fn main() { println!(\"Hello World!\");}" > roman.rs
rustc roman.rs
```
compiler crashes with this info(not sure if this is Wine or Rustc info)
```
free(): double free detected in tcache 2
```
I think that this issue is very important to fix, because Rust allows to run
tests via e.g. `cargo test` command which allows to execute tests inside
repository.
This probably will really help with testing Wine because tests are usually
small and it will be easy to track issue down.
There is a lot of rust repositories, but this two use directly windows API, so
testing them should give easy info about crashes etc.
https://github.com/microsoft/windows-samples-rshttps://github.com/microsoft/windows-rs
--
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=50804
Bug ID: 50804
Summary: LTSpice XVII will not start
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: will.nilges(a)gmail.com
Distribution: ---
Created attachment 69614
--> https://bugs.winehq.org/attachment.cgi?id=69614
.desktop startup errors
After installing LTSpice (which appears to work fine), the program will not
start, failing silently if you use the provided .desktop file (either of them),
and giving little helpful output otherwise.
I believe that LTSpice worked fine on some earlier version of Wine 6. 6.1 seems
to work.
A possibly related issue is that the installer complains at you with the
following message:
"You have User Account Control (UAC) enabled but did not 'Run As Administrator'
If you want to try to install in a directory you have full permissions, press
'YES' to continue anyway."
I'm running Fedora 33 with GNOME on Wayland. This happens on any of my Fedora
GNOME computers. I have tried no other operating system.
My current workaround is to downgrade to Wine 5.18.
--
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=51059
Bug ID: 51059
Summary: Incorrect semantics of FILE_OPEN_REPARSE_POINT on
Linux
Product: Wine-staging
Version: 6.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com,
z.figura12(a)gmail.com
Distribution: ---
This bug affects the Cygwin installer (https://cygwin.com/setup-x86_64.exe);
specifically, it fails to verify SHA512 checksums of downloaded packages.
(Source at
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=package_source.cc,
in method packagesource::check_sha512)
Running the installer with WINEDEBUG=trace+file,trace+server reports:
CreateFileW ("XXXX.tar.xz") [1]
NtCreateFile ("XXXX.tar.xz", w/o FILE_OPEN_REPARSE_POINT) [1]
CreateFileW return [1]
NtQueryInformationFile FileBasicInformation [1]
(server)close_handle [1]
NtCreateFile ("XXXX.tar.xz", w/ FILE_OPEN_REPARSE_POINT) [2]
NtReadFile [2] -> STATUS_INVALID_HANDLE
The square brackets denote file handles. Handle reuse bug has been
ruled out.
This bug can be traced to an incorrect FILE_OPEN_REPARSE_POINT implementation
in Wine-staging, in
"ntdll-Junction_Points/0016-server-Implement-FILE_OPEN_REPARSE_POINT-option.patch":
> diff --git a/server/fd.c b/server/fd.c
> index 4f43f41fb31..a01d4c9c0f7 100644
> --- a/server/fd.c
> +++ b/server/fd.c
> @@ -107,6 +107,10 @@
> #include "winioctl.h"
> #include "ddk/wdm.h"
>
> +#if !defined(O_SYMLINK) && defined(O_PATH)
> +# define O_SYMLINK (O_NOFOLLOW | O_PATH)
> +#endif
On Linux, read/write/ioctl/... operations on an O_PATH descriptor will
fail with EBADF, which is then translated as STATUS_INVALID_HANDLE to the
application.
> +
> #if defined(HAVE_SYS_EPOLL_H) && defined(HAVE_EPOLL_CREATE)
> # include <sys/epoll.h>
> # define USE_EPOLL
> @@ -1958,6 +1962,11 @@ struct fd *open_fd( struct fd *root, const char *name, struct unicode_str nt_nam
> }
> else rw_mode = O_RDONLY;
>
> +#if defined(O_SYMLINK)
> + if ((options & FILE_OPEN_REPARSE_POINT) && !(flags & O_CREAT))
> + flags |= O_SYMLINK;
Another difference is that O_PATH semantics override
O_RDONLY/O_WRONLY/O_RDWR, even if the target file isn't _actually_ a
symbolic link.
To properly implement it on Linux we should:
1. open with O_PATH.
2. check if the file is really a symlink (via fstat?).
3. if not, reopen via /proc/self/fd/%u (now w/o O_NOFOLLOW|O_PATH).
Note that this isn't an issue on XNU (macOS), where O_SYMLINK has an
equivalent semantics to FILE_OPEN_REPARSE_POINT.
--
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=50878
Bug ID: 50878
Summary: Neon Noir Benchmark crashes on Wine-Staging before
showing the first scene.
Product: Wine-staging
Version: 6.3
Hardware: x86-64
URL: https://www.cryengine.com/marketplace/product/neon-noi
r
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lvb.crd(a)protonmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Since Wine-Staging-6.3 it silent crash after clicking to start benchmark button
and loading but before scene rendering after black screen.
I'm already done bisecting. The problem appeared after this commit:
<https://github.com/wine-staging/wine-staging/commit/750044c08c49c7a117fcc91…>
Also I did some more tests on current Wine-Staging and found that
preventing the 0035 patch from applying (and all subsequent ones) - helps.
While if you add patch 0035 applying, but prevent the applying of 0036 and
subsequent - the problem appears again.
0035 patch: "ntdll: Treat undecoded unix symlinks as NT symlinks."
<https://github.com/wine-staging/wine-staging/blob/7b199110bb31100c78aa3ffb7…>
The benchmark is free, but requires registering an account and a separate
launcher to download it (it will not be necessary to run it, you can simply
copy the Neon_Noir_Ray_Tracing_Benchmark_2527 directory with it inside the
fresh prefixes).
On the site need only add the benchmark to your account
https://www.cryengine.com/marketplace/product/neon-noir
For launcher need use `WINEDLLOVERRIDES="libglesv2=d"` because Bug 44985
and `winetricks -q mfc140` need for benchmark itself Bug 44856 Bug 48866
It also seems this application requires `d3d11-Deferred_Context` from Staging,
but the strange thing is, on vanilla Wine without it, it crashes in the same
place and from the outside it seems that the behavior is identical.
Please, check it. And can anyone reproduce it.
--
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=51857
Bug ID: 51857
Summary: Support Configurable Time measurement precision for
Wine versions 5.0.x and onwards
Product: Wine
Version: 5.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: ishinberg0(a)gmail.com
Distribution: ---
`NtQuerySystemTime` used to provide timestamp value by calling `gettimeofday`,
at least on wine 4.0.x. This would provide micro-second accuracy for
timestamping used in logging,tracing, etc
On Wine 5.0.x and 6.0.x, optimizations were introduced to provide near-realtime
timestamp, relying on HAVE_CLOCK_GETTIME (which is always defined during the
`configure` phase of the wine build).
This results in milliseconds accuracy (though the resolution is still in
microseconds, it only gets updated around once every 1 ms / 1000 us.
This is not optimal for application requiring us precision for timestamp
measurement.
If this suggestion is approved, I'd be willing to contribute a PR/fix for this
issue. I also need this fix backported to 6.0.x, if possible
10x
--
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=52192
Bug ID: 52192
Summary: comctl32:propsheet fails in test_redraw() on Windows
in the Korean locale
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
comctl32:propsheet fails in test_redraw() on Windows in the Korean locale:
progress.c:156: Test failed: GetUpdateRect: There should be a region that needs
to be updated
https://test.winehq.org/data/patterns.html#comctl32:progress
The failure is not systematic but still happens over 95% of the time. So it may
be a race condition but then it is strange that it is specific to Korean and
does not ever happen in Japanese and Chinese for instance.
--
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=50319
Bug ID: 50319
Summary: Powerpoint 2013/365: cursor not moved when clicking in
current text box
Product: Wine
Version: 6.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rcorreia31(a)gmail.com
Distribution: ---
Created attachment 68898
--> https://bugs.winehq.org/attachment.cgi?id=68898
Simple Powerpoint file containing two text boxes
Running wine-6.0-rc2 compiled from source.
Same issue with previous 5.x versions.
Installation done in two different clean prefixes.
Reproduced with KDE Plama 5.20.1 and Xfce 4.16pre1, both compiled from sources,
on Centos 8.3
Both Office 32bit versions were installed using the recommendations from
WineHQ.
Office 2013 :
https://appdb.winehq.org/objectManager.php?sClass=version&iId=26323
Office 365 (2016) :
https://appdb.winehq.org/objectManager.php?sClass=version&iId=35527
Office 2013 : winetricks msxml6
Office 365 : winetricks msxml3 msxml6 riched20 riched30
Two registry updates done for 2013 and 365:
. HKCU\Software\Wine\Direct3D\MaxVersionGL (DWORD) : 30002 (hex)
. HKCU\Software\Wine\Direct2D\max_version_factory (DWORD) : 0
Two files copied for 2013 and 365:
cp "./Common Files/Microsoft Shared/ClickToRun/AppvIsvSubsystems32.dll"
"./Microsoft Office/root/Office16"
cp "./Common Files/Microsoft Shared/ClickToRun/C2R32.dll" "./Microsoft
Office/root/Office16"
Problem: clicking in the current text box does not set the cursor to the
clicked position.
To reproduce:
. Create two text boxes in Powerpoint. I.E.: one for the title and one for the
body ⇒ test case attached WineTestCase.pptx
. Add some text to both.
. Click on the text of a text box: mouse cursor is set to the right location.
. Click on another part of the text in the same current text box: text box
focus is lost and the mouse cursor is not set to where we clicked. In fact the
mouse cursor is not displayed anymore.
If we click on any character in the other non-current text box: the cursor
moves to where we clicked as expected.
So the problem only occurs when we want to put the cursor on another location
within the text box we are already in.
There are another problems that are maybe a side effect of this one:
. Double-click on a text of another text box: the text is not selected. A first
click is necessary to set the focus.
. Select a text by clicking and moving the mouse within the current text box:
the text is not selected.
No workaround found except first reselecting the text box. I.E. Esc+left click,
Right+Left click.
--
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=52194
Bug ID: 52194
Summary: In Wine version:info fails in the ar-MA locale
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: version
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
In Wine version:info fails in the Arabic (Morocco) locale:
info.c:669: Test failed: got 1025, expected lang is 6145
info.c:706: Test failed: [1] got 1025, expected lang is 6145
info.c:706: Test failed: [3] got 1025, expected lang is 6145
info.c:706: Test failed: [4] got 1025, expected lang is 6145
https://test.winehq.org/data/patterns.html#version:info
There used to be two extra failure:
info.c:709: Test failed: [0] got 1025, expected lang is 1033
info.c:709: Test failed: [2] got 1025, expected lang is 1033
However these failures got fixed by commit 472763c5237f which also fixed the
failures in all the other non-English locales (see bug 51220).
commit 472763c5237febcb8745835c96f8b49b000564de
Author: Derek Lesho <dlesho(a)codeweavers.com>
Date: Mon Dec 6 10:58:18 2021 +0100
kernelbase: Fix parameter order of FindResourceExW call for non-localized
path.
Signed-off-by: Derek Lesho <dlesho(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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=5382
--- Comment #35 from Bamm Gabriana <bammgabriana(a)gmail.com> ---
(In reply to Zebediah Figura from comment #34)
> There's currently no way to run a prefix-agnostic script like you're talking
> about in Wine. I don't think it would be excessively hard to add, on the
> other hand. The more I think about it, the more I think that it's a good
> idea...
Aww that's too bad. That means I have no choice but to run it everytime I
create a new prefix.
I was planning to incorporate such a feature in Distro Astro, a Linux-based
distribution for astronomers. The distro includes several astronomy
applications built in, some of them running under Wine. The setup is that each
has its own wine prefix. Since the distro has features like Red (Nightvision)
Mode, I was hoping to add Wine integration to it, so that software running
under Wine would obey the theme changes.
--
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.