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

[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 --- Comment #26 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Olivier F. R. Dierick from comment #23) > If someone interested picks up an issue from the AI report, how are we going > do deal with that? Should we direct the person to file a separate bug report > or to comment on this bug? > Because we'll need a way to track when one of the 1900 issues is worked > on/fixed, don't you think? That's not practical because of the large number. Many bugs get fixed without a bug report, that's not a problem. We can ask the reporter to repeat the review after some time to see what issues are left. -- 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. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 Kazim <aktaskazimcan0(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG --- Comment #8 from Kazim <aktaskazimcan0(a)gmail.com> --- > Let's close this. I think the CUPS issue has already been reported. Agreed, closing as NOTOURBUG. Thanks for the back-and-forth — the CLSCTX_INPROC_SERVER skepticism is what pointed me toward looking at the actual syscalls instead of assuming ConnectServer() itself. Filed against Throne (thronep/Throne#1814) for the IPv6 loopback handling. -- 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. 29, 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 --- Comment #25 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Stian Low from comment #22) > (In reply to Olivier F. R. Dierick from comment #17) > > I have an atypical personality. I'm not like you, any of you. > > Decades of career across industries has proved such atypical is quite > typical especially among tech/dev workers. > > Your alternative perspectives/opinions are appreciated. Hello, Thanks. Your contributions are appreciated, too. 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.

Aug. 29, 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 --- Comment #24 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Rafał Mużyło from comment #19) > Someone is trying to be passive-aggressive here and in a pretty silly way > too. I suppose that is your motive for intervening here. -- 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. 29, 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 --- Comment #23 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Alexandre Julliard from comment #21) > Olivier, please stop messing with this bug, it's fine as it is. Please just > move on. Hello, Your fascination for AI is altering your judgment and it confuses you. For as long as I've been contributing here, I have been always told that Bugzilla was not a place for user help or philosophical debate (although some senior developers tends to ignore that when they see fit), that there were policies and that bug triagers were tasked to enforce them and make sure that the bug conformed to them so that it was easier for developers to pick issues to work on. Now you're going against that, you suddenly have expectations disjointed from reality (Bugzilla is not your free customer support, we are volunteers that do not work for you and don't have to follow a "nice and welcoming to the users" code of conduct when triaging bugs, if you want that put an AI chatbox on the main page to redirect users to the appropriate places, I'm sure AI will always be nice and welcoming) and you're going to fight with the people that are contributing to the project. Why? because you're hurt by the rejection of a bug related to an AI report? I'm not responsible for the bug being changed to an enhancement request, but my understanding of the discussion is that the enhancement request is about integrating AI tool/code smeller in the development workflow. The enhancement request is not about adding AI tool/code smeller into the WINE code (I refer to the comments from Stian Low for that). So it seems logical to me to maintain coherence in the bug database that the product field is changed to gitlab. Now explain to me how triaging the bug according to the other people concensus is wrong. Isn't it just because you took a gripe against me? Note that I initially considered replying to Stian Low that bugzilla was not a place for discussion and that it should be directed at the developers mailing list, but after your interventions I guess that would have made me "too strict" and not "nice and welcoming", so I'll let you be the one that tells me to stop. And last, I will ask you to clarify several points, so that the triaging of this bug has clear and well defined instructions: If someone interested picks up an issue from the AI report, how are we going do deal with that? Should we direct the person to file a separate bug report or to comment on this bug? Because we'll need a way to track when one of the 1900 issues is worked on/fixed, don't you think? How will we have to deal with other code reviews from the same/different AI. Should we mark the reports duplicate of this one, or will they be tracked independently? Because if we accept one AI report, we'll soon get others, don't you think? How are we going to disambiguate the duplicate issues in various code reviews? Should we not list the 1900 issues to identify them? How are we going to deal with the bug when several wine releases have passed and the AI code review is no longer current? Someone have to ask Claude for a renewed code review, don't you think? Then how are we going to reproduce the code review? We'll need to know how the code review was produced. Does it use a prompt, or an interface with parameters? Then which prompt or parameters were used to produce this code review? We should ask the OP the step to reproduce the report, don't you think? 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.

Aug. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Kazim from comment #6) > I'll file this upstream with the VPN project. Given that, I think this can > likely be closed as not-a-Wine-bug, unless you'd still want Wine's CUPS > probe to use a shorter timeout as a defensive measure regardless of the > cause. Let's close this. I think the CUPS issue has already been reported. -- 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. 29, 2026

[Bug 60252] fix wow64 type cast bug + use-after-free of the demuxer context in demuxer_destroy/demuxer_create

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60252 --- Comment #8 from Peter <peter.soetens(a)gmail.com> --- The bug was surfaced by the Xwing Alliance Update 2025 project, which plays lots of videos during cut scenes. Trying to port this 32bit windows game to Linux, required WoW64 for memory pressure reasons. That crashed from time to time when playing a cut scene. Video was a H.264 High + AAC-LC in MP4. -- 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. 29, 2026

[Bug 60252] fix wow64 type cast bug + use-after-free of the demuxer context in demuxer_destroy/demuxer_create

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60252 Peter <peter.soetens(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81965|0 |1 is obsolete| | --- Comment #7 from Peter <peter.soetens(a)gmail.com> --- Created attachment 81968 --> http://bugs.winehq.org/attachment.cgi?id=81968 proper patch using git format patch from HEAD Replaces previous (hand rolled from diff) patch. This comes from a git format patch on this tree: (base) kylo ~/wine-src(wow64-fix) $ git describe wine-11.10-1-g13778d8 Bug present since wine release 9.18: 3856633a is the unixlib.c bug: https://github.com/wine-mirror/wine/commit/3856633ab5f9ec95aeb5450546fdc077… e9a9640e is the demuxer cleanup bug: https://github.com/wine-mirror/wine/commit/e9a9640e2eb692423209e5d2817fadfc… Both introduced in 2024. -- 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. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #6 from Kazim <aktaskazimcan0(a)gmail.com> --- I traced the exact syscall this reproducer blocks on — it's not WMI/ConnectServer's own logic. Wine's OLE/COM init also probes for a local CUPS server on startup, opening both an IPv6 (::1:631) and IPv4 (127.0.0.1:631) connection. The IPv4 probe returns ECONNREFUSED in ~15ms as expected. The IPv6 probe never completes — it hangs until a ~30s connect timeout. I isolated this further, with no Wine involved at all: a plain Python socket.connect(('::1', 631)) under the same VPN/TUN setup times out at 35s (my test ceiling), while ('127.0.0.1', 631) refuses instantly. With the VPN's TUN mode off, both return instantly. So this looks like a bug in the VPN's TUN implementation (it isn't excluding IPv6 loopback from the tunnel, while IPv4 loopback is excluded correctly) rather than anything in Wine. I'll file this upstream with the VPN project. Given that, I think this can likely be closed as not-a-Wine-bug, unless you'd still want Wine's CUPS probe to use a shorter timeout as a defensive measure regardless of the cause. -- 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. 29, 2026

[Bug 53241] wtsapi32:wtsapi - test_WTSEnumerateProcessesW() crashes if a process exits during the test?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=53241 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |b12b27b99c2b88064268d0a1223 | |f8beeb32947f6 --- Comment #1 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed by b12b27b99c2b88064268d0a1223f8beeb32947f6. -- 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. 29, 2026