February 2024 - Wine-Bugs - list.winehq.org

[Bug 56373] New: Autodesk Fusion: Black window and crash on 9.3

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56373 Bug ID: 56373 Summary: Autodesk Fusion: Black window and crash on 9.3 Product: Wine Version: 9.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: skala.antonin(a)gmail.com Distribution: --- Updating staging version of Wine 9.2 to 9.3 breaks Autodesk Fusion (formerly Fusion360). Only black window appear with app non responding warning and then die after a while. -- 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.

Feb. 26, 2024

[Bug 56271] Free Download Manager no longer works after it updated (stuck at 100% CPU, no visible window)

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56271 temp82(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82(a)luukku.com --- Comment #3 from temp82(a)luukku.com --- saw this on wine's gitlab. hope it helps. https://gitlab.winehq.org/wine/wine/-/merge_requests/5166 -- 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.

Feb. 26, 2024

[Bug 56359] Winedbg is broken when trying to break

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56359 --- Comment #5 from BugSeeker <rikul(a)inbox.ru> --- Created attachment 76117 --> https://bugs.winehq.org/attachment.cgi?id=76117 New log with additional steps Thanks for the quick reply! -- 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.

Feb. 26, 2024

[Bug 56372] musl based exp2() gives very inaccurate results on i686

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56372 --- Comment #1 from Martin Storsjö <martin(a)martin.st> --- For extra context; this reproduces with llvm-mingw https://github.com/mstorsjo/llvm-mingw/releases/tag/20231128. With older mingw-w64 releases, calls to exp2() go to mingw-w64-crt's internal implementation, but when targeting UCRT, with the latest few releases, the exp2() calls go to the UCRT exp2() function. -- 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.

Feb. 26, 2024

[Bug 56372] musl based exp2() gives very inaccurate results on i686

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56372 Martin Storsjö <martin(a)martin.st> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86-64 |x86 -- 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.

Feb. 26, 2024

[Bug 56372] New: musl based exp2() gives very inaccurate results on i686

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56372 Bug ID: 56372 Summary: musl based exp2() gives very inaccurate results on i686 Product: Wine Version: 8.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st CC: piotr(a)codeweavers.com Regression SHA1: ca0643875961ef62c76e0b9cbd0433002a948d9b Distribution: --- Since switching the msvcrt implementation of exp2() from internal to musl based, in ca0643875961ef62c76e0b9cbd0433002a948d9b, the accuracy on i686 has become quite bad, to the point of breaking a handful of tests in ffmpeg. The issue can be reproduced with the following test snippet: --- #include <stdio.h> #include <math.h> double input = 5.979471; int main(int argc, char* argv[]) { printf("exp2(%f) = %f\n", input, exp2(input)); return 0; } --- Prior to this commit, and with later versions on e.g. x86_64, the output is: exp2(5.979471) = 63.095753 However, on i686, the output now is: exp2(5.979471) = 62.968753 This is an error of around 0.2%, which is a couple orders of magnitudes larger than expected/tolerated. It's curious how this issue only appears on i686 though, i.e. it doesn't look like an issue with the musl exp2() implementation algorithm, but some component of it misbehaving on i686. -- 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.

Feb. 26, 2024

[Bug 56359] Winedbg is broken when trying to break

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56359 --- Comment #4 from Eric Pouech <eric.pouech(a)gmail.com> --- thanks for the log what seems to happen is - Ctrl-C is caught on console and sent to debuggee (good) ``` Ctrl-C: stopping debuggee ``` - signal handler in debuggee creates the console event dispatch thread, and debuggee catches the thread creation events (good) ``` 0118:trace:winedbg:dbg_handle_debug_event 011c:0130: create thread D @00007F08D1B229B0 ``` - but this crashes immediately, moreover at the very address of the start of the thread ``` 0118:trace:winedbg:dbg_handle_debug_event 011c:0130: exception code=c0000005 0118:trace:winedbg:dbg_handle_exception exception=c0000005 first_chance=Y 0118:trace:winedbg:dbg_handle_debug_event 011c:0130: exception code=c0000005 Unhandled exception: page fault on execute access to 0x00007f08d1b229b0 in 64-bit code (0x007f08d1b229b0). ``` (and afterwards - actually winedbg restarts because the access violation isn't handled by first instance - the faulty address isn't present in process address space) as I can't repro here, I'll ask for more info (esp. to try to grasp where we end up in this faulty address) could send back the log (+winedbg) of the session, using the following winedbg commands > info share > info maps > p &ntdll.so!p__wine_ctrl_routine > disas ntdll.so!p__wine_ctrl_routine > watch * &ntdll.so!p__wine_ctrl_routine > cont TIA -- 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.

Feb. 26, 2024

[Bug 56359] Winedbg is broken when trying to break

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56359 --- Comment #3 from BugSeeker <rikul(a)inbox.ru> --- Reproduced on latest stable released version wine-9.0 using custom build on RedHat7.9. Console log with +winedbg channel is attached. -- 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.

Feb. 26, 2024

[Bug 56359] Winedbg is broken when trying to break

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56359 --- Comment #2 from BugSeeker <rikul(a)inbox.ru> --- Created attachment 76116 --> https://bugs.winehq.org/attachment.cgi?id=76116 winedbg log file: -- 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.

Feb. 26, 2024

[Bug 56357] Zero sized writes using WriteProcessMemory succeed on Windows, but fail on Wine.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=56357 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC| |eric.pouech(a)gmail.com --- Comment #1 from Eric Pouech <eric.pouech(a)gmail.com> --- Wine currently implements Windows 7 & 8 behavior to fail on 0-length writes. Windows 10 & 11 behavior has changed and now succeeds on 0-length writes. Created https://gitlab.winehq.org/wine/wine/-/merge_requests/5162 A+ -- 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.

Feb. 26, 2024