https://bugs.winehq.org/show_bug.cgi?id=47198
--- Comment #30 from Andrew Wesie awesie@gmail.com --- (In reply to mail+wine from comment #29)
For me it's also not 100% stable.
Agreed. Just with practice modes I was able to reproduce at least one crash. I haven't debugged it enough yet to know if it is related to this issue or something else. For me, the crash will happen right before I would normally see these lines in the output:
014b:fixme:process:NtQueryInformationProcess ProcessCookie (0xffffffff,0x10408c34,0x00000004,(nil)) stub 014b:fixme:ntdll:NtQuerySystemInformation SystemExtendedProcessInformation, len 1048576, buffer 0x3c64020, stub!
So I'm going to have to look closer at where NtQueryInformationProcess is getting called.
Would be interesting to get some deeper insight into this issue. Why does using "seccomp" have any impact here? Is this just an attempt to block some stuff that is done by League?
There are many ways to do a system call on Windows. LoL now does it in one of the more annoying ways for Wine to properly emulate.
Why is this "memory expansion" needed? Just to store some info? Would it be possible to just malloc the right amount of memory and then store the pointer to this memory into the pthread struct memory?
This is similar to some other issues that Wine has on other platforms / architectures. I suggest reading this question: https://stackoverflow.com/questions/53244454/how-did-wine64-manage-to-handle.... We basically have the same issue now with glibc, so the patch reserves some extra space that can be used by Wine without interfering with glibc's use of %gs.