diff options
author | Mike Kaganski <mike.kaganski@collabora.com> | 2024-02-28 03:48:55 +0600 |
---|---|---|
committer | Mike Kaganski <mike.kaganski@collabora.com> | 2024-02-28 04:57:11 +0100 |
commit | 072a25e1ef4815bbef4f18f59f025862a0d8e876 (patch) | |
tree | 591dc8d16b98cabf0766a4bf541a15bdd424ad86 /config_host/config_fuzzers.h.in | |
parent | 0c643e8afdf8b0b929b603340979e771eeb9fc0b (diff) |
tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0
This partially reverts commit ed259e5efe432386b54c553cbc644b3b64976852
(Upgrade external/boost to latest Boost 1.81.0, 2023-01-05), which had
dropped the patch previously introduced with commit
f046fed2782f0d4244aff719ba70a56399a2583a (Don't ever attempt to initialise
a std::locale with a UTF-8 locale on Windows, 2018-05-17).
It seems that there is a nightmare going on in MSVCRT, and tdf#157135
is caused by dome MS bug. The problem happens in a deeply nested call
to mbstowcs_s (several levels deep from std::locale constructor with
name of "en_US.UTF-8"), which gets a non-null wcstr and sizeInWords
equal to zero, which generates an invalid argument handler, resulting
in a failed assertion "(pwcs == nullptr && sizeInWords == 0) || (pwcs
!= nullptr && sizeInWords > 0)" in _mbstowcs_internal from
minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp:245, and a crash.
The crashreporter initiates, but since it tries to use CRT itself,
which is in fastfail mode, it hangs.
The patch that is restored here was intended for something different;
but it happily workarounds the nightmare. Until the proper fix found,
let it be.
Change-Id: Ic978f87e2e7b81fc2e1cd182a4247084ad016a9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164068
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Diffstat (limited to 'config_host/config_fuzzers.h.in')
0 files changed, 0 insertions, 0 deletions