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

[Bug 34694] New: Adobe reader 11.0.4 empty search results in PDF portfolios
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=34694 Bug #: 34694 Summary: Adobe reader 11.0.4 empty search results in PDF portfolios Product: Wine Version: 1.7.3 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: nick.payne(a)internode.on.net Classification: Unclassified Created attachment 46244 --> http://bugs.winehq.org/attachment.cgi?id=46244 Expanded search results under Wine Reader 11.0.4 with flash support for viewing PDF portfolios installed on Linux Mint 15 amd64. Download of Adobe Reader XI 11.0.4: ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.04/en_US/AdbeRdr11004_en… Download of Flash player/plugins: http://www.adobe.com/support/flashplayer/downloads.html#fp11 Some example portfolio for testing: http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/feature-detai… For installation you need to work around bug 12501 -> 'winetricks mspatcha' After installation you need to work around bug 25834 (disable protected mode), bug 16144 (work around with 'winetricks atmlib'), and richedit component bug with 'winetricks riched20'. You can now search a portfolio and get back a search window showing hits in the various PDF files in the portfolio, but the results are unusable because the expanded results window doesn't contain any text for the search hits and they can't be selected to jump to the relevant location in the PDF file where the hit occurred. See the two uploaded screen dumps, showing the expanded results window from performing the same search on a PDF portfolio using firstly Reader 11.0.4 under wine and then Reader 11.0.4 running on winxp. At the point where I expand the search results (and find they're all empty), I see the following on the console output: fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),1,3,(nil),0,(nil)) - stub! fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:qmgr:BITS_IBackgroundCopyJob_GetPriority Not implemented fixme:qmgr:BITS_IBackgroundCopyJob_SetPriority (0x59750,0x00000001) stub fixme:qmgr:BITS_IBackgroundCopyJob_GetPriority Not implemented fixme:qmgr:BITS_IBackgroundCopyJob_AddFile Check for valid filenames and supported protocols fixme:wininet:InternetLockRequestFile STUB fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented -- 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.

3 7

[Bug 60245] New: Threadpool worker retirement cancels pending overlapped I/O after callback returns
by WineHQ Bugzilla Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=60245 Bug ID: 60245 Summary: Threadpool worker retirement cancels pending overlapped I/O after callback returns Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: megadjc(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81952 --> http://bugs.winehq.org/attachment.cgi?id=81952 Two-patch series implementing ThreadIsIoPending and preventing threadpool worker retirement while thread-owned asynchronous I/O is pending. Wine can cancel ordinary overlapped I/O issued by a threadpool callback when the callback returns and the worker later becomes idle. I encountered this with DxO PureRAW 4, where a Qt threadpool callback issues an overlapped ReadFile() on a named pipe and returns while the read remains pending. Wine subsequently retires that worker after its threadpool worker timeout, which terminates the issuing thread and cancels the outstanding read. This can also be reproduced with a standalone Windows test and does not depend on PureRAW or Qt. Observed Wine behavior ====================== The relevant sequence is: threadpool callback -> ReadFile(named pipe, ..., OVERLAPPED) -> ReadFile returns FALSE / ERROR_IO_PENDING -> callback returns -> worker becomes idle -> Wine worker retirement timeout expires -> worker thread terminates -> pending overlapped read is cancelled -> GetOverlappedResult() reports ERROR_OPERATION_ABORTED With Wine's current: #define THREADPOOL_WORKER_TIMEOUT 5000 the PureRAW failure occurs reproducibly at approximately 5.05 seconds after the worker becomes idle. As an initial diagnostic experiment, changing only that timeout from 5000 ms to 60000 ms caused PureRAW to work correctly. This is not intended as the fix; it demonstrated that worker retirement was causing the I/O cancellation. Native Windows behavior ======================= I tested the corresponding behavior on Windows 11 with standalone programs. First, ordinary thread termination behaves as Wine currently expects: * A thread issues an ordinary overlapped named-pipe ReadFile(). * ReadFile returns ERROR_IO_PENDING. * The issuing thread exits. * The operation is cancelled. * GetOverlappedResult() returns ERROR_OPERATION_ABORTED (995). So Wine's general behavior of cancelling thread-owned asynchronous I/O when an ordinary thread terminates appears correct. Threadpool workers behave differently. Using a custom Windows threadpool with several workers: * one worker issued an ordinary overlapped named-pipe read and returned from its callback while the read remained pending; * the other workers owned no pending I/O; * the pool minimum was subsequently lowered so the workers became eligible for retirement. On native Windows, the workers with no I/O were retired, while the exact worker owning the pending overlapped read remained alive. In my native test the no-I/O workers were still alive at 65 seconds and had terminated by the 66-second sample. This is only an observed boundary and is not intended to imply that Windows has an internal 65-second timeout. The I/O-owning worker remained alive beyond that point. After data was written to the other end of the pipe, the pending read completed successfully. ThreadIsIoPending ================= The native behavior appears to be exposed through the ThreadIsIoPending thread information class. On native Windows: Ordinary event-backed overlapped named-pipe read while pending: NtQueryInformationThread(ThreadIsIoPending) status = STATUS_SUCCESS value = 1 length = sizeof(ULONG) After the operation is no longer pending: value = 0 An IOCP-backed operation that remains valid after the issuing thread terminates reports: value = 0 The IOCP operation also survives issuing-thread termination and later completes successfully. This matches the distinction Wine already makes when cancelling asynchronous operations during thread termination. I additionally tested the native ThreadIsIoPending query contract: * the output size must be exactly sizeof(ULONG); * invalid lengths return STATUS_INFO_LENGTH_MISMATCH; * a NULL output buffer with the correct size returns STATUS_ACCESS_VIOLATION; * THREAD_QUERY_INFORMATION access is required; * THREAD_QUERY_LIMITED_INFORMATION and SYNCHRONIZE alone are insufficient; * a valid handle to an already terminated thread succeeds and returns zero; * failed queries leave the output and ReturnLength untouched. Wine cause ========== Wine associates asynchronous operations with the issuing server thread. When a thread terminates, server/thread.c calls: cancel_terminating_thread_asyncs(thread) and pending async operations associated with that thread are normally cancelled. There is already an exception for operations associated with an I/O completion port and no event: if (async->completion && async->data.apc_context && !async->event) continue; Those operations survive thread termination, matching the native IOCP test above. The threadpool worker retirement code in dlls/ntdll/threadpool.c does not currently check whether terminating the worker would cancel pending I/O. Consequently an idle worker can be retired while an ordinary overlapped operation issued by one of its callbacks is still pending. Proposed fix ============ I have a two-patch series which: 1. Implements ThreadIsIoPending. The server uses the same predicate for both ThreadIsIoPending and cancel_terminating_thread_asyncs(), so the query reports exactly the asynchronous operations whose lifetime is tied to the queried thread. 2. Changes threadpool worker retirement so that, when a worker would otherwise retire, it queries ThreadIsIoPending and remains alive while such I/O is pending. Wine's existing 5000 ms worker timeout is left unchanged. Regression test =============== The patch series adds a deterministic regression test using a custom two-worker threadpool. The test: 1. creates two worker threads; 2. occupies one worker with a blocking callback; 3. has the second worker issue an overlapped named-pipe ReadFile(); 4. allows that callback to return while the read remains pending; 5. verifies that callback completion has occurred; 6. lowers the pool minimum and releases the blocking worker; 7. waits longer than Wine's worker-retirement timeout; 8. verifies that the worker owning the pending I/O is still alive; 9. writes to the other end of the pipe; 10. verifies that the read completes successfully. Without the worker-retirement fix, terminating the issuing worker cancels the read. With the fix, no-I/O workers retire normally while the I/O-owning worker is retained until the operation completes. Application impact ================== This was originally found with DxO PureRAW 4. PureRAW uses Qt named-pipe IPC. Under unmodified Wine the relevant connection is lost approximately five seconds after the callback that issued the pending read returns. A diagnostic Wine build with THREADPOOL_WORKER_TIMEOUT increased from 5000 to 60000 ms avoids the failure. The proposed patches do not change the timeout and do not contain any PureRAW-specific behavior; they implement the native threadpool/I/O semantics instead. Testing ======= Tested with: * native Windows 11 standalone conformance tests; * upstream Wine without the fix; * upstream Wine with the proposed patches; * DxO PureRAW 4; * dlls/kernel32/tests/thread.c; * dlls/ntdll/tests/threadpool.c. The existing ntdll/threadpool test suite has an unrelated pre-existing todo-success failure concerning timer merging. The proposed tests do not introduce an additional failure. -- 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 4

[Bug 17414] New: user32/dde test crashes if +heap enabled
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=17414 Summary: user32/dde test crashes if +heap enabled Product: Wine Version: 1.1.15 Platform: PC URL: http://test.winehq.org/data/6a1537c4b5037be5253c33021fda 3a02430533f7/wine_xp_ae-ub-810-heap/riched32:editor.html OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: enhancement Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=19484) --> (http://bugs.winehq.org/attachment.cgi?id=19484) backtrace in 1.1.15 wine: Unhandled page fault on read access to 0x00130000 at address 0x6045971b (thread 0009), starting debugger... ... =>0 0x6045971b CompareStringW+0x13b(lcid=1033, style=0, str1=0x130000, len1=0, str2=0x6074c780, len2=-1) [/home/austin/wine-git/dlls/kernel32/../../include/wine/unicode.h:216] in kernel32 (0x0032f848) 1 0x6045bed4 lstrcmpW+0x64(str1=<register EDI not in topmost frame>, str2=<register ESI not in topmost frame>) [/home/austin/wine-git/dlls/kernel32/locale.c:2834] in kernel32 (0x0032f878) 2 0x60681d7a dde_server_wndprocW+0x3da(hwnd=0xe0028, msg=1000, wparam=458798, lparam=<register EDI not in topmost frame>) [/home/austin/wine-git/dlls/user32/tests/dde.c:1215] in user32_test (0x0032f8b8) 3 0x6082337a WINPROC_wrapper+0x1a() in user32 (0x0032f8e8) 4 0x608237ca call_window_proc+0x6a(hwnd=<register EDI not in topmost frame>, msg=<register ESI not in topmost frame>, wp=458798, lp=1204994, result=0x32f998, arg=0x606819a0) [/home/austin/wine-git/dlls/user32/winproc.c:458] in user32 (0x0032f928) 5 0x60828af7 WINPROC_call_window+0xf7(hwnd=<register EDI not in topmost frame>, msg=1000, wParam=458798, lParam=1204994, result=0x32f998, unicode=1, mapping=WMCHAR_MAP_DISPATCHMESSAGE) [/home/austin/wine-git/dlls/user32/winproc.c:2218] in user32 (0x0032f968) 6 0x607e7ee6 DispatchMessageW+0x96(msg=<register EDI not in topmost frame>) [/home/austin/wine-git/dlls/user32/message.c:3122] in user32 (0x0032f9a8) 7 0x607a4037 WDML_SyncWaitTransactionReply+0xe7(hConv=0x1254b8, dwTimeout=<register ESI not in topmost frame>, pXAct=0x125508, ack=0x32fb84) [/home/austin/wine-git/dlls/user32/dde_client.c:1069] in user32 (0x0032fa08) 8 0x607a4b21 DdeClientTransaction+0x651(pData="test dde command", cbData=17, hConv=0x1254b8, hszItem=0xdead, wFmt=48879, wType=16464, dwTimeout=1000, pdwResult=0x32fb84) [/home/austin/wine-git/dlls/user32/dde_client.c:1225] in user32 (0x0032fa68) 9 0x60686158 test_dde_aw_transaction+0x638() [/home/austin/wine-git/dlls/user32/tests/dde.c:1374] in user32_test (0x0032fb98) ... 216 while (*s) s++; Attached is the backtrace...I've stripped out +heap, so the output is readable, but easily reproducible. -- 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.

3 21

[Bug 28816] New: kernel32/tests/loader.ok fails under valgrind
by wine-bugs＠winehq.org Aug. 28, 2026

Aug. 28, 2026

http://bugs.winehq.org/show_bug.cgi?id=28816 Bug #: 28816 Summary: kernel32/tests/loader.ok fails under valgrind Product: Wine Version: 1.3.30 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified Under Valgrind, "make loader.ok" fails with log loader.c:375: Test failed: 2: 0x10002000 != 0 loader.c:376: Test failed: 2: 1 != 0 loader.c:378: Test failed: 2: 2000 != MEM_FREE loader.c:379: Test failed: 2: 20000 != 0 -- 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.

3 10

[Bug 60176] New: Submit app broken
by WineHQ Bugzilla Aug. 27, 2026

Aug. 27, 2026

http://bugs.winehq.org/show_bug.cgi?id=60176 Bug ID: 60176 Summary: Submit app broken Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: dimesio(a)earthlink.net Target Milestone: --- Distribution: --- Originally reported by a user on the forum (https://forum.winehq.org/viewtopic.php?t=43115) and I was able to confirm. Clicking Submit app now produces a page asking for the app name, and after you enter the name and click submit, it gives you a list of every app entry in the database, with no way to go any further. It should show a list of possible matches, along with the form to submit a new application and test report. This may be related to the changes made to fix bug 58228; the list does have a pager. -- 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 60242] New: winedbg hits assertion on setting breakpoint.
by WineHQ Bugzilla Aug. 27, 2026

Aug. 27, 2026

http://bugs.winehq.org/show_bug.cgi?id=60242 Bug ID: 60242 Summary: winedbg hits assertion on setting breakpoint. Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bernhardu(a)mailbox.org Target Milestone: --- Distribution: --- Created attachment 81943 --> http://bugs.winehq.org/attachment.cgi?id=81943 debugging.txt With regular winehq devel packages for Debian trixie 11.16~trixie-1, I hit following assert when trying to set a breakpoint. err:msvcrt:_wassert (L"NULL != abbrev_entry",L"dlls/dbghelp/dwarf.c",465) Attached file shows the details. -- 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 60240] New: gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs
by WineHQ Bugzilla Aug. 27, 2026

Aug. 27, 2026

http://bugs.winehq.org/show_bug.cgi?id=60240 Bug ID: 60240 Summary: gdi32/win32u: memory font without OS/2 table is skipped by the font engine, breaking embedded fonts of LibreOffice-generated PDFs Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: exmov71(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81939 --> http://bugs.winehq.org/attachment.cgi?id=81939 trace, reproducer, proposed fix LibreOffice (tested with 24.8) exports PDF files with subset-embedded TrueType fonts that contain no `OS/2` table. When such a document is opened in a WPF-based viewer running under wine (in our case DevExpress Xpf.PdfViewer, .NET Framework 4.7.2), all glyphs of these fonts render as boxes/nothing. On native Windows 11 the very same document and application display correctly. WINEDEBUG=+font pinpoints the cause — dlls/win32u/freetype.c, new_ft_face(): ``` 0024:trace:font:new_ft_face Loading font from ptr 0x... size 9160, index 0 0024:trace:font:new_ft_face Font (null)/0x... lacks either an OS2, HHEA or HEAD table. Skipping this font. ``` The loader requires OS/2 **and** HHEA **and** HEAD to be present. The LibreOffice subsetter emits head/hhea but never OS/2, so every embedded font of such documents is silently dropped. Minimal reproducer (attached): * `lo.ttf` — TrueType subset extracted from a problem PDF (no OS/2 table, only a Macintosh (1,0) format-0 cmap; produced by LibreOffice); * `a_os2.ttf` — byte-identical file except a synthesized minimal OS/2 v4 table added; * `addfont_probe.cs/.csproj` — tiny C# console program calling gdi32!AddFontMemResourceEx on both files. Results under wine-11.16: ``` lo.ttf -> AddFontMemResourceEx returns NULL ("Skipping this font" in +font log) a_os2.ttf -> registered OK, fontsAdded=1 ``` Full trace excerpt attached (`wine_trace_excerpt.txt`). Note for triage: native Windows 11 applies *different* additional requirements in AddFontMemResourceEx itself (it rejects both attached files, apparently because of the missing Unicode cmap). The divergence relevant to this report is that Windows font loaders used by real applications (WPF / DirectWrite path) happily consume the OS/2-less font — the LibreOffice document renders fine on Windows 11 — while wine's loader rejects it solely because of the missing OS/2 table. Since LO-exported PDFs are extremely common, any PDF viewer relying on the Wine font engine is affected. -- 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 12

[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 Aug. 26, 2026

Aug. 26, 2026

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.

1 2

[Bug 12428] New: win16 test suite: profile test fails
by wine-bugs＠winehq.org Aug. 26, 2026

Aug. 26, 2026

http://bugs.winehq.org/show_bug.cgi?id=12428 Summary: win16 test suite: profile test fails Product: Wine Version: CVS/GIT Platform: PC URL: http://win16test.googlecode.com OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=11967) --> (http://bugs.winehq.org/attachment.cgi?id=11967) Backtrace in git +++ This bug was initially created as a clone of Bug #9850 +++ The code can be downloaded from http://win16test.googlecode.com with svn, and is quite easy to run; see http://win16test.googlecode.com/svn/trunk/src/README for instructions. The profile test crashes in current git. Attached is the backtrace in current git. -- 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.

3 12

[Bug 60210] New: conhost: set_tty_attr() uses "\x1b[m" to reset foreground color to 7, inadvertently wiping the background color
by WineHQ Bugzilla Aug. 26, 2026

Aug. 26, 2026

http://bugs.winehq.org/show_bug.cgi?id=60210 Bug ID: 60210 Summary: conhost: set_tty_attr() uses "\x1b[m" to reset foreground color to 7, inadvertently wiping the background color Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: unxed(a)mail.ru Target Milestone: --- Distribution: --- In programs/conhost/conhost.c, set_tty_attr() is responsible for converting Win32 CHAR_INFO color attributes to ANSI escape sequences for tty output: if ((attr & 0x0f) != (console->tty_attr & 0x0f)) { if ((attr & 0x0f) != 7) { ... sprintf(buf, "\x1b[%um", n); tty_write( console, buf, strlen(buf) ); } else tty_write( console, "\x1b[m", 3 ); } When a console cell transitions from a colored foreground (e.g. 0x001B: Cyan on Blue background) to default Light Gray text on the same non-black background (0x0017: Light Gray on Blue background): 1. ((attr & 0x0f) != (console->tty_attr & 0x0f)) evaluates to true (7 != 11). 2. The 'else' branch executes and sends "\x1b[m". 3. In ANSI terminal emulation, "\x1b[m" (SGR 0) resets ALL attributes, including the background color (resetting it to terminal default / black). 4. Next, the background check: if ((attr & 0xf0) != (console->tty_attr & 0xf0) && attr != 7) evaluates to false because both the current cell and console->tty_attr have (attr & 0xf0) == BACKGROUND_BLUE (0x10). 5. As a result, conhost does not re-emit the background escape sequence (e.g. "\x1b[44m"). 6. console->tty_attr is updated to 0x0017. Result: The terminal background is reset to black by "\x1b[m", while conhost's internal state tracker believes the terminal is still using BACKGROUND_BLUE. All subsequent cells with attribute 0x0017 are rendered on a black background instead of the requested blue background. Expected behavior: To reset only the foreground color without corrupting the background, conhost should emit "\x1b[39m" (default foreground color) instead of "\x1b[m", or force a background re-emission if (attr & 0xf0) != 0. Original report: https://github.com/unxed/f4/issues/536 -- 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