https://bugs.winehq.org/show_bug.cgi?id=52362
Bug ID: 52362 Summary: Powershell Core 7 installer hangs forever on Chinese locale (LC_ALL=zh_Han.UTF-8) Product: Wine Version: 7.0-rc3 Hardware: x86-64 URL: https://github.com/PowerShell/PowerShell/releases/down load/v7.1.5/PowerShell-7.1.5-win-x64.msi OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: xerox.xerox2000x@gmail.com Distribution: ---
Hi, someone i was trying to help someone to get this installed and he reported this to me (I couldn`t reproduce it), that the installer hung for him, and in fact he found that it was due to the fact he was running with LC_ALL=zh_Han.UTF-8
I don`t know anything about these chinese locales, but report anyway as could be a bug in wine (?).
reproduce: LC_ALL=zh_Han.UTF-8 5ine msiexec /i PowerShell-7.1.5-win-x64.msi
A +relay shows it`s looking for files in directory zh-CN which is not there, though there is zn-Han(s) directories. But just copying zh-Han to zh-CN didn`t help either.
Anyway, I guess someone with more knowledge about (Chinese) locales would have lots more clues than i have...
https://bugs.winehq.org/show_bug.cgi?id=52362
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Powershell Core 7 installer |Powershell Core 7 installer |hangs forever on Chinese |hangs forever on Chinese |locale |locale (LANG=zh_CN.UTF-8) |(LC_ALL=zh_Han.UTF-8) |
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Edit, it should be LANG=zh_CN.UTF-8
So reproduce: LANG=zh_CN.UTF-8 wine msiexec /i PowerShell-7.1.5-win-x64.msi
https://bugs.winehq.org/show_bug.cgi?id=52362
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Powershell Core 7 installer |Powershell Core 7 installer |hangs forever on Chinese |hangs forever on Chinese |locale (LANG=zh_CN.UTF-8) |locale (LC_ALL=zh_CN.UTF-8)
--- Comment #2 from Louis Lenders xerox.xerox2000x@gmail.com --- grrr, sorry for the mess, it should be: LC_ALL=zh_CN.UTF-8
so:
LC_ALL=zh_CN.UTF-8 wine msiexec /i PowerShell-7.1.5-win-x64.msi
https://bugs.winehq.org/show_bug.cgi?id=52362
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- ...if I were to offer (an unasked for) blind guess, I'd say this is likely to go toward bug 10767 - after all, it's a MS semi-core program that's been likely tested in pretty much every available locale by now, so it likely be something that's sort of works in wine, but is still done fundamentally wrong.
That is unless it's something as obscure as not being able to handle existence of both zh_CN and zh_TW.
See how the order of accessing changes with locale (if you got patience for it, you can check that relay log for CompareString calls to exclude my guess being the case).
https://bugs.winehq.org/show_bug.cgi?id=52362
--- Comment #4 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rafał Mużyło from comment #3)
...if I were to offer (an unasked for) blind guess, I'd say this is likely to go toward bug 10767 -
As far as I understand, Staging has a patch for that bug, but Staging doesn`t allow the installer to succeed as well :(
https://bugs.winehq.org/show_bug.cgi?id=52362
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Louis Lenders from comment #4)
As far as I understand, Staging has a patch for that bug, but Staging doesn`t allow the installer to succeed as well :(
If you're referring to the mentioned in the bug, ...well, if (as it seems) it's still generates the sortkeys based on DUCET, it's likely still getting things wrong. The way I very vaguely recall it, one of the later Fabian Maurer's patches generated the keys based on MS data, but I'm not sure if the version in staging does.
Of course my guess on the reason might simply be wrong, though did you see those CompareString calls before entering that endless loop ?
https://bugs.winehq.org/show_bug.cgi?id=52362
--- Comment #6 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rafał Mużyło from comment #5)
Of course my guess on the reason might simply be wrong, though did you see those CompareString calls before entering that endless loop ?
AFAICT it seems like it: 0ad8:Call KERNEL32.GetProcAddress(7b600000,6448a205bb6 "CompareStringEx") ret=00c579e5 . 0ad8:Call KERNEL32.CompareStringEx(016a152c L"",08000001,016b3b1c L"abcdefghijklmnopqrstuvwxyz",0000001a,016b3b6c L"ABCDEFGHIJ KLMNOPQRSTUVWXYZ",0000001a,00000000,00000000,00000000) ret=6448a4c41b8 .
0ad8:Ret KERNEL32.CompareStringEx() retval=00000002 ret=6448a4c41b8 . Shortly after begins endless sequence of:
09ac:Call KERNEL32.GetFileAttributesExW(016b63cc L"C:\Program Files\PowerShell\7\zh-CN\System.Management.Automation.resources.dll",00000000,228eb0d0) ret=6448a3d61f3 . 09ac:Ret KERNEL32.GetFileAttributesExW() retval=00000000 ret=6448a3d61f3
and
0ad8:Call KERNEL32.GetFileAttributesExW(017604e4 L"C:\Program Files\PowerShell\7\zh-CN\Microsoft.PowerShell.ConsoleHost.resources.dll",00000000,0019a3b0) ret=6448a3d61f3 . 09ac:Ret KERNEL32.GetFileAttributesExW() retval=00000000 ret=6448a3d61f3
I now noticed that those files are not present in directory zn-Hans either, they reside one directory higher. So I`m rather puzzled as to what causes this...
https://bugs.winehq.org/show_bug.cgi?id=52362
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- ...you know, it can be something zh specific after all...
Going by one of the tests for kernel32, zh_CN and zh_Hans are mapped to each other, but perhaps here we're hitting a portion of the code where the mapping is incomplete...but if that would be the case why didn't it work when you copied one dir to the other ?
https://bugs.winehq.org/show_bug.cgi?id=52362
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #8 from Louis Lenders xerox.xerox2000x@gmail.com --- Somehow this is fixed, maybe by the recent locale related changes/patches (?)
Anyway, resolving fixed
https://bugs.winehq.org/show_bug.cgi?id=52362
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.8.