This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jkloth
Recipients CharlieClark, Dominik Geldmacher, Manjusaka, eryksun, jkloth, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2019-05-12.01:02:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I have managed to setup a VM that can reproduce the error.  Unfortunately, the error (heap corruption) is coming from within the UCRT.  Attempting to work around that, I came across another error in the UCRT.

Due to these errors in all available UCRT versions, the only available solution is to re-implement %Z handling in Python's implementation of strftime().

@steve.dower: If you could forward the following information to the interested parties for faster response, it would be great.

Everyone else, what follows contains UCRT internal details which is of no interest to Python.

In wcsftime() [ucrt\time\wcsftime.cpp, line 1018], the call to _mbstowcs_s_l() doesn't handle the error case of EILSEQ.  This error happens when the tzname (originally set by __tzset() from the Unicode name in the registry encoded to the ACP) contains an undecodable character.  In the 'de_DE' case, \u00E4.  _mbstowcs_s_l returns without changing `wnum` (which is 0).  The 'Z' case then blindly subtracts 1 (wnum=-1) and advances the string pointer, now pointing *before* the start when the format is just L"%Z" (like Python has).  Now when wcsftime() is returning it stores a '\0' at that current position thus causing a heap corruption.

Ok, no deal breaker, we can just update the _tzname array when we call setlocale().  Alas, another error :(  If _tzset() is called a second time, it fails when encoding the Unicode name due to an uninitialized variable.  In tzset_from_system_nolock() [ucrt\time\tzset.cpp, line 158], the function __acrt_WideCharToMultiByte() [appcrt\locale\widechartomultibyte.cpp] does not set the `lpUsedDefaultChar` flag when FALSE.  This is only an issue, it seems, on subsequent calls as `used_default_char` can be non-zero prior to the call.  A non-zero value there, causes the tzname to be set to the empty string even if the conversion succeeded.
Date User Action Args
2019-05-12 01:02:14jklothsetrecipients: + jkloth, paul.moore, vstinner, tim.golden, zach.ware, eryksun, steve.dower, Manjusaka, CharlieClark, Dominik Geldmacher
2019-05-12 01:02:14jklothsetmessageid: <>
2019-05-12 01:02:14jklothlinkissue36792 messages
2019-05-12 01:02:13jklothcreate