Am 28.06.25 um 11:13 schrieb Stephen Kitt:
Hi Bernhard,
On Wed, 25 Jun 2025 17:07:38 +0200, Bernhard Übelacker
<bernha...@mailbox.org> wrote:
Am 25.06.25 um 01:38 schrieb Bernhard Übelacker:
Applying the patch [1] (at least the upper half) makes winecfg no
longer crash and showing its window as expected.
[1]
https://gitlab.winehq.org/wine/wine/-/commit/5c45391e9f79854915c50a15054f2de4888596a2
Just a short addition:
When using these two upstream patches, both may apply cleanly:
https://gitlab.winehq.org/wine/wine/-/commit/398da92511b51d3ee4ce7c77bfe6d738621bfbfa
https://gitlab.winehq.org/wine/wine/-/commit/5c45391e9f79854915c50a15054f2de4888596a2
Thanks for the investigation, I added both to ~repack-6. The resulting
package seems to work for me; since you were able to reproduce the bug more
reliably, would you be able to check whether it’s fixed in ~repack-6 for you
too?
Regards,
Stephen
Hello Stephen,
I fired up my trixie/testing VM (with the last available i386 kernel)
and first got with 10.0~repack-5 just this:
benutzer@debian:~$ winecfg
wine: Unhandled page fault on execute access to 00406000 at address
00406000 (thread 002c), starting debugger...
002c:err:seh:start_debugger Couldn't start debugger L"winedbg --auto 40 32"
(2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
wine: could not load kernel32.dll, status c0000135
benutzer@debian:~$
After installing 10.0~repack-6 starting winecfg once,
then going back to 10.0~repack-5, I got the recursive behaviour:
benutzer@debian:~$ winecfg
wine: Unhandled page fault on execute access to 00402E80 at address
00402E80 (thread 002c), starting debugger...
wine: Unhandled page fault on execute access to 00457560 at address
00457560 (thread 0034), starting debugger...
wine: Unhandled page fault on execute access to 00457560 at address
00457560 (thread 0044), starting debugger...
wine: Unhandled page fault on execute access to 00412C40 at address
00412C40 (thread 003c), starting debugger...
...
So another data point is, the recursive aspect comes just into play when
there exists a fully configured wine prefix.
With 10.0~repack-6, in a very short test, I received no longer any such crashes.
Kind regards,
Bernhard
