October 2022 - Wine-Bugs - list.winehq.org

[Bug 53737] Incoming (game): crashes after the intro video

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53737 --- Comment #12 from Prajna Sariputra <putr4.s(a)gmail.com> --- The bisection excluding dfd5f109 and reverting said commit before every build reports the first bad commit as deaf0891b096628cf99e58834c39a45a6c99c54c (2 May, first appearing in release 7.10), which is: > ntdll: Improve block size rounding compatibility. > This also increase the default heap size to 2MiB (32bit) / 4MiB (64bit), > for the tests to pass. Unfortunately that commit does not revert cleanly on top of master, but doing so on 7.10 does make the game work in addition to also reverting dfd5f109. So, here are the additional test results: 7.9 minus dfd5f109: ok 7.10 minus dfd5f109: fail 7.10 minus dfd5f109 and deaf0891: ok The fail case there also has `0100:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory.` in the terminal output. I can upload the whole output+backtrace if needed, although I'm guessing it won't be any more helpful given that it looks like deaf0891 is just like dfd5f109 in that they happen to push the memory usage just past the limit. -- 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.

Oct. 5, 2022

[Bug 53760] New: 0x7b00fd36

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53760 Bug ID: 53760 Summary: 0x7b00fd36 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wing32 Assignee: wine-bugs(a)winehq.org Reporter: pat.laferriere2344(a)gmail.com Distribution: --- Unhandled exception: 0x0eedfade in 32-bit code (0x7b00fd36). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:006b GS:0063 EIP:7b00fd36 ESP:0062ed34 EBP:0062eda8 EFLAGS:00200246( - -- I Z- -P- ) EAX:0062ed40 EBX:0062ee3c ECX:00000018 EDX:0062edec ESI:0eedfade EDI:00000007 Stack dump: 0x0062ed34: 0128c7e1 0062edd4 0128c7ea 0eedfade 0x0062ed44: 00000001 00000000 7b00fd36 00000007 0x0062ed54: 0120d028 04a4b000 04a4afa0 0120d25b 0x0062ed64: 0062fbc0 0062ee3c 0062ee08 0128111c 0x0062ed74: 01139385 04520e00 011396ab 00000001 0x0062ed84: 04520e00 01139707 0eedfade 0062edbc Backtrace: =>0 0x7b00fd36 EntryPoint+0xffffffff() in kernelbase (0x0062eda8) 1 0x012813e2 EntryPoint+0xffffffff() in stpass (0x0062edd4) 2 0x0120d028 EntryPoint+0xffffffff() in stpass (0x0062ee3c) 3 0x0120d269 EntryPoint+0xffffffff() in stpass (0x0062fc10) 4 0x0120cb42 EntryPoint+0xffffffff() in stpass (0x0062fc30) 5 0x0120cb22 EntryPoint+0xffffffff() in stpass (0x0062fc40) 6 0x01219e0e EntryPoint+0xffffffff() in stpass (0x0062fcb4) 7 0x0120cbb8 EntryPoint+0xffffffff() in stpass (0x0062fce0) 8 0x0120caf1 EntryPoint+0xffffffff() in stpass (0x0062fcfc) 9 0x01219e0e EntryPoint+0xffffffff() in stpass (0x0062fd90) 10 0x01207b27 EntryPoint+0xffffffff() in stpass (0x0062fdb0) 11 0x011f9e16 EntryPoint+0xffffffff() in stpass (0x0062fdd8) 12 0x01200b3c EntryPoint+0xffffffff() in stpass (0x0062fdf8) 13 0x01200bca EntryPoint+0xffffffff() in stpass (0x0062fe28) 14 0x0121b90a EntryPoint+0xffffffff() in stpass (0x0062fe70) 15 0x013e3505 EntryPoint+0xffffffff() in stpass (0x0062fea8) 16 0x01d7ad46 EntryPoint+0xffffffff() in stpass (0x0062ff10) 17 0x00401ea2 EntryPoint+0xffffffff() in stpass (0x0062ff30) 18 0x7b62e270 EntryPoint+0xffffffff() in kernel32 (0x0062ff48) 19 0x7bc5bc77 EntryPoint+0xffffffff() in ntdll (0x0062ff5c) 20 0x7bc5bed0 EntryPoint+0xffffffff() in ntdll (0x0062ffec) 0x7b00fd36 EntryPoint+0xffffffff in kernelbase: subl $4,%esp Modules: Module Address Debug info Name (53 modules) PE 1c0000- 1e3000 Deferred userenv PE 400000- 413000 Export stpass PE 630000- ab6000 Deferred ole32 PE 1130000- 373d000 Export stpass PE 3740000- 38b1000 Deferred winmm PE 38c0000- 38e3000 Deferred zlib1 PE 38f0000- 3b7f000 Deferred comdlg32 PE 3b80000- 402b000 Deferred comctl32 PE 47b0000- 47c9000 Deferred olepro32 PE 4ac0000- 4d56000 Deferred gdiplus PE 4ef0000- 52c4000 Deferred windowscodecs PE 61740000-61828000 Deferred advapi32 PE 61940000-61b30000 Deferred wininet PE 62fc0000-631f2000 Deferred rpcrt4 PE 63480000-6349c000 Deferred version PE 637c0000-638bd000 Deferred oleacc PE 63bc0000-63c02000 Deferred shcore PE 64a40000-64b5e000 Deferred shlwapi PE 64ec0000-652ab000 Deferred oleaut32 PE 65580000-655a3000 Deferred wtsapi32 PE 66240000-6627e000 Deferred bcrypt PE 68080000-680c5000 Deferred jsproxy PE 68500000-6864b000 Deferred combase PE 68700000-6878e000 Deferred uxtheme PE 68a40000-68ab8000 Deferred xmllite PE 69180000-691a5000 Deferred wsock32 PE 69600000-69710000 Deferred winhttp PE 69940000-699b3000 Deferred propsys PE 6a040000-6a0a3000 Deferred msacm32 PE 6a280000-6a4c9000 Deferred msvcrt PE 6bc00000-6bca2000 Deferred sechost PE 6bcc0000-6be9c000 Deferred setupapi PE 6c9c0000-6cf3f000 Deferred gdi32 PE 6db40000-6db72000 Deferred imagehlp PE 6e8c0000-6eb65000 Deferred crypt32 PE 6ed00000-6f392000 Deferred user32 PE 6f4c0000-6f570000 Deferred wintrust PE 6f900000-6fa1c000 Deferred msctf PE 6fa80000-6fcbb000 Deferred dbghelp PE 70940000-70997000 Deferred mpr PE 70b40000-70df7000 Deferred ucrtbase PE 70e80000-70e93000 Deferred msimg32 PE 71200000-71248000 Deferred imm32 PE 7b000000-7b30b000 Dwarf kernelbase PE 7b600000-7b928000 Dwarf kernel32 PE 7bc00000-7bee0000 Dwarf ntdll PE 7dbf0000-7dbf4000 Deferred winex11 PE 7e910000-7e91b000 Deferred winspool PE 7e960000-7f237000 Deferred shell32 PE 7f3a0000-7f3a4000 Deferred dnsapi PE 7f3c0000-7f3c4000 Deferred iphlpapi PE 7f3f0000-7f3f3000 Deferred netapi32 PE 7f430000-7f436000 Deferred ws2_32 Threads: process tid prio (all id:s are in hex) 00000038 services.exe 0000003c 0 00000040 0 0000004c 0 00000064 0 00000084 0 000000a0 0 000000ec 0 00000044 svchost.exe 00000048 0 00000054 0 00000058 0 0000005c winedevice.exe 00000060 0 00000068 0 0000006c 0 00000070 0 00000074 explorer.exe 00000078 0 0000009c 0 000000ac 0 0000007c plugplay.exe 00000080 0 00000088 0 0000008c 0 00000090 0 000000bc 0 00000094 winedevice.exe 00000098 0 000000a4 0 000000a8 0 000000b8 0 000000c4 0 000000e4 rpcss.exe 000000e8 0 000000f0 0 000000f4 0 000000f8 0 000000fc 0 00000100 0 0000015c DFX.exe 00000160 0 00000170 0 00000174 0 00000184 DfxSharedApp32.exe 000000e0 0 000000b4 DfxSharedApp64.exe 000000dc 0 00000234 (D) C:\Program Files (x86)\Sticky Password\stpass.exe 00000238 0 <== 00000244 0 System information: Wine build: wine-6.0.3 (Ubuntu 6.0.3~repack-1+zorin1) Platform: i386 (WOW64) Version: Windows 7 Host system: Linux Host version: 5.15.0-48-generic -- 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.

Oct. 5, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #6 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- Created attachment 73231 --> https://bugs.winehq.org/attachment.cgi?id=73231 Working patch Here's a maybe-less-hacky patch based on your initial approach, but taken farther. This actually does get wineboot to succeed and cmd.exe will launch; haven't tested it further than that yet. I changed it so the __wine_jmp_buf and NTSTATUS belong to KeUserModeCallback, and are passed in (and represented in the user_callback_frame) as pointers so we don't have to deep-copy anything. This actually makes them a bit more consistent the usage pattern of ret_ptr and ret_len in NtCallbackReturn, so that part seems OK. I was then getting SIGBUS errors due to the stack not being properly aligned; I thought this was due to call_user_mode_callback lacking WINAPI, but that didn't help (I add it though, since that seems right; KeUserModeCallback had it). It turns out the actual reason is that it was the __wine_jmpbuf that had been giving user_callback_frame its alignment, and with that gone the compiler didn't see any reason to. the syscall_frame becomes $sp, so it has its own reason to need 16 byte alignment, so I added that DECLSPEC_ALIGN. I think my fudging of the STATUS_STACK_OVERFLOW path is probably still dubious, but all it was really checking before was "some pointer on the stack of KeUserModeCallback", since we already know &callback_frame wasn't actually the bottom of that stack frame. Suggestions welcome. -- 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.

Oct. 5, 2022

[Bug 49543] Several games require bcrypt DH support

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49543 --- Comment #14 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to muetakappaepsilon from comment #13) > Any update on getting this into the trunk of wine? We would like to avoid adding another library dependency. Someone tried to add ECDH support to GnuTLS a while ago (which could be generalized to handle both DH and ECDH) but it seems the effort has stalled: https://gitlab.com/gnutls/gnutls/-/merge_requests/1395 -- 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.

Oct. 4, 2022

[Bug 53737] Incoming (game): crashes after the intro video

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53737 --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- So I am not sure that attribution of the regression to commit dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d is fully correct (although of course it increased VM usage a bit). If possible, it would be interesting to further bisect the regression after that blamed commit by doing the bisect starting from the next after dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d and applying the revert on each step. It can be done by putting the revert as a patch and doing 'git apply revert.patch' at each step, then 'git reset --hard' after build. Yet I think the most interesting is why it is so close to VM exhaustion even before dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d, the major issue (if there is indeed a specific one and not just borderline VRAM usage by the game plus usual pulseaudio etc. overhead) is probably elsewhere. That needs some debugging. -- 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.

Oct. 4, 2022

[Bug 53737] Incoming (game): crashes after the intro video

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53737 --- Comment #10 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73230 --> https://bugs.winehq.org/attachment.cgi?id=73230 Terminal output + backtrace (master minus dfd5f109fb4) The line below does indeed still exist in this log: > 010c:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory. -- 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.

Oct. 4, 2022

[Bug 53759] New: FPGA Programmer can't open port

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53759 Bug ID: 53759 Summary: FPGA Programmer can't open port Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 7Cattac(a)gmail.com Distribution: --- Created attachment 73229 --> https://bugs.winehq.org/attachment.cgi?id=73229 output log I'm trying to use FPGA Programmer (https://www.fpga-cores.com/software/fpga-programmer/) to broadcast UPD packages to my FPGA. Starting it up has no issues, but when it depends a device in the network it hangs for a couple of minutes and the app runs very slowly. Trying to upload a .bin takes a long time and gives an error saying "can't open port", when that happens "010c:fixme:progress:ProgressWindowProc state 2 not yet handled" is spammed in the logs. Wine version: Wine-staging 7.18 FPGA Programmer version: 1.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.

Oct. 4, 2022

[Bug 53737] Incoming (game): crashes after the intro video

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53737 --- Comment #9 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Paul Gofman from comment #8) > From the log: > I am not sure if we can do anything sensible about it now, I don't have > immediate feasible ideas how we can deal with variable kernel stack size > (and I think reverting it to the older size will break more than fix). Long > term with 32 on 64 that shouldn't be an issue as kernel stack is going to be > 64 bit. Here I mean the change introduced by the blame commit specifically. Outside of that (especially if reverting the commit of top on master yields the same VRAM exhaustion), it looks a bit weird that a ddraw game hits that, it may happen that there are issues in ddraw or elsewhere which lead to excessive VRAM usage which can be fixed. -- 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.

Oct. 4, 2022

[Bug 53737] Incoming (game): crashes after the intro video

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53737 --- Comment #8 from Paul Gofman <pgofman(a)codeweavers.com> --- >From the log: > 010c:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory. While blaming that commit which increased kernel stack size is not random (it increased the amount of VRAM used per thread), it is noted in the previous comment that it doesn't help anymore on top of current master (so unless it is an unrelated regression some other changes also increased VRAM usage for the game). It would be great to see the log with the commit reverted on top of git master to confirm if that is the same VRAM exhaustion issue. I am not sure if we can do anything sensible about it now, I don't have immediate feasible ideas how we can deal with variable kernel stack size (and I think reverting it to the older size will break more than fix). Long term with 32 on 64 that shouldn't be an issue as kernel stack is going to be 64 bit. -- 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.

Oct. 4, 2022

[Bug 53758] New: Prototype freezes and crashes after intro/in menu

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53758 Bug ID: 53758 Summary: Prototype freezes and crashes after intro/in menu Product: Wine Version: 7.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: odecif(a)gmail.com Distribution: --- Created attachment 73228 --> https://bugs.winehq.org/attachment.cgi?id=73228 Execution log After a fresh install from DVD-disc on a clean 64-bit prefix, if I run the game using "WINEPREFIX=<prefix> wine prototypef.exe" in the games installation folder, the game start up showing a cinematic of some license-text and the developers logo and transfers to the games main menu. Here a modal shows with some information regarding save game and here is when the game freezes. winetricks dxvk removes said freeze and the game is playable. GTX 760M i5-6300HQ Budgie DE Manjaro 22 Kernel 5.4.212-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.

Oct. 4, 2022