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

[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 #18 from Martin Storsjö <martin(a)martin.st> --- (In reply to Kevin Puetz from comment #16) > > I wonder where I'm missing an initialization of it > > I think you're missing it in _wine_syscall_dispatcher itself, when entered > in the "normal" case (i.e. output_syscalls in tools/winebuild/import.c, when > calling a function which the .spec file declared as `-syscall`). In that > case the id is in x8, and the syscall_frame is built up on the stack (via > all the code prior to the 3: label that __wine_syscall_dispatcher_return is > jumping back to). > > Or to put it another way, there should be an `str sp, [x10, #0x120]` > somewhere in the vicinity of > https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/ > signal_arm64.c#L1304-1319 to initialize your new syscall_stack (no longer > just alignment padding) along with everything else as it builds up a new > syscall_frame. Or something like that (haven't actually tested this)... No, that's not it - on entry to __wine_syscall_dispatcher, we have an already allocated syscall_frame somewhere on the kernel stack, where we just fill in the register values from the userspace registers - the point being here that we already need to have syscall_frame set up and syscall_stack set. Whenever we allocate a new syscall_frame on the kernel stack, we'd need to set syscall_stack in it to point to the intended stack boundary. But I found it; while signal_init_process sets up the syscall stack, void *kernel_stack = (char *)ntdll_get_thread_data()->kernel_stack + kernel_stack_size; arm64_thread_data()->syscall_frame = (struct syscall_frame *)kernel_stack - 1; call_init_thunk then later wipes the frame and sets it up: memset( frame, 0, sizeof(*frame) ); NtSetContextThread( GetCurrentThread(), ctx ); frame->sp = (ULONG64)ctx; frame->pc = (ULONG64)pLdrInitializeThunk; frame->x[0] = (ULONG64)ctx; frame->x[18] = (ULONG64)teb; frame->prev_frame = NULL; frame->restore_flags |= CONTEXT_INTEGER; frame->syscall_table = KeServiceDescriptorTable; pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL ); __wine_syscall_dispatcher_return( frame, 0 ); If I set up syscall_stack here, it works as I had expected. (In reply to Kevin Puetz from comment #17) > > there's a slight risk of clobbering the stack below sp at that point I believe > > Yeah, I see no indications that wine uses sigaltstack outside of wineserver, > so there's at least the chance of an ill-timed signal coming in and smashing > things up if sp is *ever* pointed at syscall_frame rather than the actual > top-of-stack. If signals use the normal stack, you can't just use sp as > scratch register even in asm that will eventually put it back. Ok, good that we agree on that :-) I'll attach both of those patches too, for reference. With that, we've got three different ways of fixing this issue: 1. Separate noinline function that sets up the syscall_frame 2. Add a gap on the stack to compensate for the difference between bottom of stack and syscall_frame 3. Keep track of the bottom of the syscall stack and the syscall frame separately Two of them are watertight - 2. isn't, but it is dead simple (but needs overestimating how much extra stuff the compiler might add in the stack frame, below syscall_stack). In the end, I would maybe perhaps still lean towards your patch, i.e. 1. here - it's simple and straightforward and doesn't need extra logic in assembly. The fact that part of the compiler generated stack gets clobbered during later syscalls is the only thing that feels odd with it, but it shouldn't make any practical difference. -- 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. 24, 2022

[Bug 53828] LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53828 --- Comment #2 from Jactry Zeng <jactry92(a)gmail.com> --- Hi, You are using Wine 5.0 which is pretty out of date, please retest it with the current development version. -- 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. 24, 2022

[Bug 53828] LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53828 --- Comment #1 from MR.LAU <ookay1980(a)yahoo.com.hk> --- Additionally, the WINE console has this message: 0009:err:ole:CoGetClassObject class {854d7ac5-bc3d-11d0-b421-00a0c90f9dc4} not registered 0009:err:ole:CoGetClassObject class {854d7ac5-bc3d-11d0-b421-00a0c90f9dc4} not registered 0009:err:ole:CoGetClassObject no class object {854d7ac5-bc3d-11d0-b421-00a0c90f9dc4} could be created for context 0x3 0009:err:ddeml:DdeConnect This Conv already exists: (0x7de150) 0009:err:ddeml:DdeConnect This Conv already exists: (0x7de150) 0009:err:ddeml:DdeConnect This Conv already exists: (0x7de150) -- 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. 24, 2022

[Bug 53828] New: LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53828 Bug ID: 53828 Summary: LINUX RUNNING FOXPRO 6.0 DDE to MSFT WORD97 FAILURE Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ookay1980(a)yahoo.com.hk Distribution: --- Created attachment 73358 --> https://bugs.winehq.org/attachment.cgi?id=73358 backtrace dump after WINE abend Under LINUX MINT 20.2 (LOCALE is set to BIG5 Hong Kong) I run MSFT Visual Fox Pro 6.0 and MSFT OFFICE 97 Pro SR2 (Chinese Hong Kong version) The VFP program tried to DDE to WORD97 and run a MACRO to open a DOCUMENT. When I run it in normal WINDOWS ME and WINDOWS XP, it will switch to WORD97 and ran the MACRO to display the WORD DOCUMENT smoothly and automatically. When I run it in LINUX MINT 20.2 and WINE 5.0 It does not switch to WORD97. I have to manually switch to WORD97. The Macro seem to run OK as it displayed the DOC and allowed me to edit the DOC. However, after a few more CLICKs on the WORD screen, WINE abended (the backtrace.txt is saved and attached) Normally when I run OFC97 under WINE without the VFP DDE stuff, it works fine with only some minor issues. It seem to also have some DDE registration issue. -- 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. 24, 2022

[Bug 53575] Subtitle Workshop Classic 6.1.4 disabled menu items are not viewable at all with Light theme

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53575 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Closing. -- 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. 24, 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 #17 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- > there's a slight risk of clobbering the stack below sp at that point I believe Yeah, I see no indications that wine uses sigaltstack outside of wineserver, so there's at least the chance of an ill-timed signal coming in and smashing things up if sp is *ever* pointed at syscall_frame rather than the actual top-of-stack. If signals use the normal stack, you can't just use sp as scratch register even in asm that will eventually put it back. -- 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. 24, 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 #16 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- > I wonder where I'm missing an initialization of it I think you're missing it in _wine_syscall_dispatcher itself, when entered in the "normal" case (i.e. output_syscalls in tools/winebuild/import.c, when calling a function which the .spec file declared as `-syscall`). In that case the id is in x8, and the syscall_frame is built up on the stack (via all the code prior to the 3: label that __wine_syscall_dispatcher_return is jumping back to). Or to put it another way, there should be an `str sp, [x10, #0x120]` somewhere in the vicinity of https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar… to initialize your new syscall_stack (no longer just alignment padding) along with everything else as it builds up a new syscall_frame. Or something like that (haven't actually tested this)... -- 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. 24, 2022

[Bug 53804] Namh Depends on Microsoft.WindowsAppRuntime.dll and will not start without it.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53804 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://www.nexusmods.com/n | |ierautomata/mods/140/?tab=d | |escription -- 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. 23, 2022

[Bug 53617] Imaris fails at exit with error, and keeps a process running.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53617 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian Version|7.16 |7.19 -- 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. 23, 2022

[Bug 53819] some versions of Unity engine need GetWindowTheme implemented to properly display crash dialog

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53819 --- Comment #3 from Rafał Mużyło <galtgendo(a)o2.pl> --- (In reply to Zhiyi Zhang from comment #2) > GetWindowTheme is implemented. This looks like a delay load problem. ...when you put it that way, given the initial crash is (as I've already said) most likely virtual mapping space exhaustion, it might be that a (slightly bogus) OOM condition is raised at the time, preventing proper load... -- 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. 23, 2022