August 2026 - Wine-Bugs - list.winehq.org

[Bug 60240] gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60240 --- Comment #4 from AZh <exmov71(a)gmail.com> --- Created attachment 81946 --> http://bugs.winehq.org/attachment.cgi?id=81946 TestApp binaries part 2 -- 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.

Aug. 27, 2026

[Bug 60240] gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60240 --- Comment #3 from AZh <exmov71(a)gmail.com> --- Created attachment 81945 --> http://bugs.winehq.org/attachment.cgi?id=81945 TestApp binaries part 1 -- 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.

Aug. 27, 2026

[Bug 60240] gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60240 --- Comment #2 from AZh <exmov71(a)gmail.com> --- Created attachment 81944 --> http://bugs.winehq.org/attachment.cgi?id=81944 TestApp sources -- 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.

Aug. 27, 2026

[Bug 60241] Claude Core review report(a lot of copy paste and logic bugs uncovered)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60241 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Ken Sharp from comment #1) > 1 Find ONE bug. > 2. Report it. > 3. GOTO 1 > > Don't use AI. That doesn't seems like a reasonable approach. -- 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.

Aug. 27, 2026

[Bug 54836] GrandMA3 onPC Version 1.9.2.2 page fault on startup (1.8.8.2 worked fine)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=54836 --- Comment #12 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Austin English from comment #11) > (In reply to Hans Leidekker from comment #9) > > Wine already treats builtin dll signatures as trustworthy if the certificate > > chain leads to a trusted root CA but these signing certificates cost money > > and it seems unlikely that Linux distributions would take on this task. > > Is this documented? You mean signing builtin dlls? You could use standard Windows tools to do it. On Linux there's osslsigncode (ignoring timestamping): for dll in $(ls *.{dll,sys,drv,acm}); do echo "Signing $dll" osslsigncode sign -pkcs12 signcert.p12 -in $dll -out $dll.signed if [ $? -ne 0 ]; then exit 1 fi mv $dll.signed $dll chmod +x $dll # osslsigncode doesn't preserve executable bit done > > An alternative might be to include a script that generates a self-signed > > signing certificate when Wine is installed, signs Wine dlls with it and adds > > the corresponding CA to the local trust database. > > I think this is a great idea, and either this ticket should be repurposed > for that, or a new one opened. I think this is actually a packaging bug but I would keep this one or a new one open to collect duplicates. -- 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.

Aug. 27, 2026

[Bug 54836] GrandMA3 onPC Version 1.9.2.2 page fault on startup (1.8.8.2 worked fine)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=54836 --- Comment #11 from Austin English <austinenglish(a)gmail.com> --- (In reply to Hans Leidekker from comment #9) > Wine already treats builtin dll signatures as trustworthy if the certificate > chain leads to a trusted root CA but these signing certificates cost money > and it seems unlikely that Linux distributions would take on this task. Is this documented? > An alternative might be to include a script that generates a self-signed > signing certificate when Wine is installed, signs Wine dlls with it and adds > the corresponding CA to the local trust database. I think this is a great idea, and either this ticket should be repurposed for that, or a new one opened. -- 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.

Aug. 27, 2026

[Bug 60243] Uncaught C++ exception in a DLL static initializer is only reported when the throwing frame has no cleanup landing pad

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60243 --- Comment #1 from Madison Steiner <awsmadi(a)amazon.com> --- Regression status: this is not a regression, so I have left Regression SHA1 empty. The reporting path this bug is about has never worked on x86-64. The TEB-frame walk in RtlUnwindEx was bounded by end_frame from the moment it was introduced: /* 98b8160b732, 2009-06-17, "ntdll: Add support for calling the TEB exception chain handlers on x86_64", first released in wine-1.1.24 */ while ((ULONG64)teb_frame < new_context.Rsp && (ULONG64)teb_frame < end_frame) On an exit unwind end_frame is null, so the loop body never executes and the loader's handler is never reached. That bound survived unchanged until 1ad0e3fed68 (2026-06-30) removed it for bug 59850, so it was present in every release from 1.1.24 through 11.12. Measured with the case D reproducer from the description, on four builds, all identical -- exit 5, no err:module:loader_init, two "invalid frame" errors: 9.0, 10.0, 11.0, 11.15 Case A (the same code without the cleanup frame) reports correctly on all four, exit 67. So the two halves are: before 11.13 the walk is skipped entirely, and from 11.13 the walk does run -- instrumenting it shows "calling TEB handler" going from 1 occurrence to 2 -- while every observable outcome stays the same. That residual failure is what this bug reports. One correction in case anyone repeats the archaeology: `git log -S 'teb_frame < end_frame'` credits 2e81ba5f4ff (2011-01-26, "include: Add a prototype for RtlUnwindEx on x86_64"), but that commit only retyped end_frame from ULONG64 to PVOID and added casts, which changes the literal string and so registers as an occurrence-count change. It did not introduce the bound. 98b8160b732 did. -- 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.

Aug. 26, 2026

[Bug 60243] Uncaught C++ exception in a DLL static initializer is only reported when the throwing frame has no cleanup landing pad

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60243 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source -- 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.

Aug. 26, 2026

[Bug 60241] Claude Core review report(a lot of copy paste and logic bugs uncovered)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60241 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- 1 Find ONE bug. 2. Report it. 3. GOTO 1 Don't use AI. -- 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.

Aug. 26, 2026

[Bug 60243] New: Uncaught C++ exception in a DLL static initializer is only reported when the throwing frame has no cleanup landing pad

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60243 Bug ID: 60243 Summary: Uncaught C++ exception in a DLL static initializer is only reported when the throwing frame has no cleanup landing pad Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: awsmadi(a)amazon.com Target Milestone: --- Distribution: --- When a C++ exception escapes a DLL's static initializers, Wine's loader normally reports the failing module by name from loader_init() (dlls/ntdll/loader.c): err:module:loader_init "throwdll.dll" failed to initialize, aborting err:module:loader_init Initializing dlls for L"...\A.exe" failed, status 20474343 That only happens when there are no cleanup frames between the throw and the loader. Add a single local object with a destructor to the throwing initializer and the diagnostic disappears completely: the process exits with status 5 (STATUS_ACCESS_VIOLATION truncated to its low byte) having printed nothing at all on either stdout or stderr. This matters in practice because essentially every real static initializer constructs an object with a destructor, so the silent path is the common one and the reported path is the rare one. STEPS TO REPRODUCE Two ~20-line cases that differ only by one local object. Built with mingw-w64 GCC 15.3.0 for x86_64-w64-mingw32, -O0 -g, shared libstdc++. Case A, no cleanup frame: #include <stdexcept> struct Boom { Boom() { throw std::runtime_error("boom from a DLL static initializer"); } }; static Boom boom; extern "C" __declspec(dllexport) int touch(void) { return 1; } Case D, identical plus one local object whose destructor is out-of-line so it cannot be elided: #include <stdexcept> struct Noisy { ~Noisy(); }; Noisy::~Noisy() {} struct Boom { Boom() { Noisy n; throw std::runtime_error("boom from a DLL static initializer"); } }; static Boom boom; extern "C" __declspec(dllexport) int touch(void) { return 1; } Each is linked into an executable that calls touch(), so the DLL loads at process start and the initializer runs during PROCESS_ATTACH. Run each under wine. ACTUAL RESULTS case cleanup frame 11.0 11.15 output A no rc=67 rc=67 err:module:loader_init "throwdll.dll" failed to initialize D yes rc=5 rc=5 nothing at all For case D, WINEDEBUG=+seh ends: trace:seh:RtlUnwindEx code=20474343 flags=7 end_frame=0000000000000000 target_ip=0000000000000000 err:seh:RtlUnwindEx invalid frame 00007FFFFE300008 (00007FFFFE102000-00007FFFFE300000) trace:seh:RtlRestoreContext returning to 0000000000000000 stack 00007FFFFE300008 trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) addr=0000000000000000 err:seh:call_seh_handlers invalid frame 00007FFFFE300008 (00007FFFFE102000-00007FFFFE300000) err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. The establisher frame is StackBase + 8, eight bytes past the top of the stack, so is_valid_frame() (dlls/ntdll/signal_x86_64.c:259 and :735) rejects it and sets EXCEPTION_STACK_INVALID. Control then transfers to RIP 0, and the resulting access violation cannot be dispatched either. The process is killed at dlls/ntdll/unix/thread.c:1660 with rec->ExceptionCode. EXPECTED RESULTS Case D reports the failing module by name, as case A does. RELATIONSHIP TO BUG 59850 Bug 59850 ("Exit unwind is broken") is fixed in 11.15 and the fix does engage here, but it is not sufficient. Instrumenting the TEB-frame walk shows "calling TEB handler" going from 1 occurrence on 11.0 to 2 on 11.15, so the previously-skipped handler now runs, while every observable outcome is unchanged: no err:module:loader_init, the same two "invalid frame" errors, the same exit 5. For reference, 11.0 has the pre-fix loop and 11.15 has the fixed one: /* 11.0, dlls/ntdll/signal_x86_64.c:779-781. On an exit unwind end_frame is null, so teb_frame < 0 is never true and the body never runs. */ while (is_valid_frame( (ULONG_PTR)teb_frame ) && (ULONG64)teb_frame < new_context.Rsp && (ULONG64)teb_frame < (ULONG64)end_frame) /* 11.15, dlls/ntdll/signal_x86_64.c:778-781 */ ULONG_PTR last_frame = new_context.Rsp; if (end_frame && (ULONG_PTR)end_frame < last_frame) last_frame = (ULONG_PTR)end_frame; while (is_valid_frame( (ULONG_PTR)teb_frame ) && (ULONG_PTR)teb_frame < last_frame) WHY THE NULL end_frame IS CORRECT ON THE CALLER'S SIDE libgcc writes the unwind target into private_[1]/private_[2] only inside the _URC_HANDLER_FOUND branch of _GCC_specific_handler (libgcc/unwind-seh.c), and zeroes them at throw time. With no C++ handler anywhere on the stack, which is the situation before main(), that branch never runs, so _Unwind_Resume passes zeros to RtlUnwindEx. Requesting an exit unwind with a null target frame is documented and correct; the problem is in honouring the request. The number of target-less exit unwinds equals the number of cleanup frames, so one cleanup frame is enough to trigger this. DOWNSTREAM CONTEXT Found while porting Nix to Windows. It made a cross-compiled test binary exit 5 with zero bytes on both streams, which three of Nix's five unit-test suites did. Write-up: https://github.com/NixOS/nix/issues/16356 Tested with nixpkgs' wineWow64Packages.stable (11.0) and .unstable (11.15) on NixOS, x86_64. -- 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.

Aug. 26, 2026