https://bugs.winehq.org/show_bug.cgi?id=45453
Bug ID: 45453 Summary: Guild Wars 2: Launcher crashes with assertion "jobThreads && (jobThreads <= hardwareThreads)" Product: Wine Version: 3.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: stormy.t.dragon@gmail.com Distribution: ---
Created attachment 61791 --> https://bugs.winehq.org/attachment.cgi?id=61791 WINE 3.12 Console Dump
When starting Guild Wars 2 under WINE 3.11 or WINE 3.12, the launcher crashes with an internal assertion "jobThreads && (jobThreads <= hardwareThreads)".
Reverting to WINE 3.10 allows the launcher to start normally.
Another user reported having no problems with WINE 3.12, so this may be specific to certain distros or hardware.
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #1 from Stormy Dragon stormy.t.dragon@gmail.com --- Created attachment 61792 --> https://bugs.winehq.org/attachment.cgi?id=61792 Guild Wars 2 Log
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #2 from Stormy Dragon stormy.t.dragon@gmail.com --- Created attachment 61793 --> https://bugs.winehq.org/attachment.cgi?id=61793 WINE 3.10 Console Dump
For comparison purposes, the corresponding dump when it is run under WINE 3.10
https://bugs.winehq.org/show_bug.cgi?id=45453
Juha Lepola fluxie@kapsi.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fluxie@kapsi.fi
--- Comment #3 from Juha Lepola fluxie@kapsi.fi --- Created attachment 62458 --> https://bugs.winehq.org/attachment.cgi?id=62458 git bisect log
Located the commit that causes the problem, at least for me. Attached the log from the "git bisect".
The first "bad" commit is as follows:
1312c6642851d4a0c5de9a71c824800935f96691 is the first bad commit commit 1312c6642851d4a0c5de9a71c824800935f96691 Author: Roderick Colenbrander thunderbird2k@gmail.com Date: Wed Jun 20 22:29:44 2018 -0700
ntdll: Report physical cores once with proper thread mask.
Signed-off-by: Roderick Colenbrander thunderbird2k@gmail.com Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=45453
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |1312c6642851d4a0c5de9a71c82 | |4800935f96691 CC| |joseph.kucia@gmail.com Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=45453
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com Component|-unknown |ntdll
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #4 from Juha Lepola fluxie@kapsi.fi --- I think I know what the problem is. The command "cat /sys/devices/system/cpu/cpu0/topology/thread_siblings" reports two different siblings masks separated with a comma on my machine: "00000000,00010001".
The implementation in the function "create_logical_proc_info" seems to parse only the first mask. Because the first mask is only zeros the number of logical CPUs will be zero on my machine. I have ThreadRipper 1950X.
Parsing the siblings from "/sys/devices/system/cpu/cpu0/topology/thread_siblings_list" would be more straightforward if more inefficient. But on the other hand, if we used "thread_siblings_list" to create the "thread_mask" mask in "create_logical_proc_info" then we wouldn't have to read "thread_siblings" at all.
I can write a patch but I would like to know if it was acceptable to use "thread_siblings_list" instead of "thread_siblings"?
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #5 from Juha Lepola fluxie@kapsi.fi --- Ok, so the actual variable that controls the format of "thread_siblings" is the number of CPUs Linux kernel is compiled to support. I had my mine set to 64. Once I changed that to 32, Guild Wars 2 started to work without any other changes.
I don't know the default value distributions are generally using so I cannot say how severe this issue actually is. The current implementation in "create_logical_proc_info" could reasonably support up to 64 logical processors. The limiting factor after that is that it cannot report multiple processor groups. https://docs.microsoft.com/en-us/windows/desktop/ProcThread/processor-groups
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #6 from Stormy Dragon stormy.t.dragon@gmail.com --- On my system (i7-7820X), /sys/devices/system/cpu/cpu0/topology/thread_siblings has three masks:
00,00000000,00000101
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #7 from Roderick Colenbrander thunderbird2k@gmail.com --- Thanks for reporting the issue. Can you check what the output of the cache entries for the different cache levels for each core on your system? (/sys/devices/system/cpuX/cacheX/shared_cpu_map). I suspect some of these values could be wrong too. When I last looked at this code I wasn't too happy about most of it. I have been considering to rewrite portions of it (e.g. add helper functions to retrieve some of the values as some of the sys parsing is likely common).
When I last looked at these issues the following tools / samples were useful as well: - Sysinternals core info application uses GetLogicalProcessorInformationEx: https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo - Example application on GetLogicalProcessorInformation:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683194(v=vs.85).a...
Double check if their output matches Wine and Windows.
https://bugs.winehq.org/show_bug.cgi?id=45453
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #8 from Stormy Dragon stormy.t.dragon@gmail.com --- Created attachment 62609 --> https://bugs.winehq.org/attachment.cgi?id=62609 i7-7820X Cache Information
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #9 from Stormy Dragon stormy.t.dragon@gmail.com --- I attached the requested information about the cache levels.
The system in question does not dual boot Windows, so I unfortunately cannot help with the WINE vs. Windows comparison.
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #10 from Roderick Colenbrander thunderbird2k@gmail.com --- Created attachment 62712 --> https://bugs.winehq.org/attachment.cgi?id=62712 Proof-of-concept patch
An initial patch, which I expect will fix your issues. I couldn't fully test it as my bitmasks are different, but give it a try. If it works I will split the patch and submit them.
https://bugs.winehq.org/show_bug.cgi?id=45453
--- Comment #11 from Stormy Dragon stormy.t.dragon@gmail.com --- You patch seems to fix the problem for me. (Sorry for the slow reply, I'd never compiled Wine from source before and it took me a while to figure out all the dependencies).
https://bugs.winehq.org/show_bug.cgi?id=45453
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #12 from Roderick Colenbrander thunderbird2k@gmail.com --- Patch got merged, should be in the upcoming Dec 7th release.
https://bugs.winehq.org/show_bug.cgi?id=45453
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b9af36933fdf47cbbe139626e98 | |750da72142dce
https://bugs.winehq.org/show_bug.cgi?id=45453
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc1.