Calling DateTime.Now causes memory corruption when machine has many language packs installed
#55307
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
MSBuild .zip, MSbuild.dll under \sdk\6.0.100-preview.6.21327.1 has been attached. |
vdanche
changed the title
|
Based on the exception this could be related to this change: #52992 |
|
This is an external issue. I will follow up with component owners regarding possible workarounds. |
AntonLapounov
changed the title
DateTime.Now causes memory corruption when machine has many language packs installed
dotnet-issue-labeler
bot
added
area-System.Globalization
untriaged
|
Tagging subscribers to this area: @tarekgh, @safern Issue DetailsMachine OS: win7 SP1 Repro steps: In CLI, execute below command. Expected Result: Actual Result:
Read our privacy statement online: If the online privacy statement is not available, please read our privacy statement offline: Note:
|
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsMachine OS: win7 SP1 Repro steps: In CLI, execute below command. Expected Result: Actual Result:
Read our privacy statement online: If the online privacy statement is not available, please read our privacy statement offline: Note:
|
|
@mattjohnsonpint @tarekgh @stephentoub
Note that |
Do you have more info why this causing heap corruption? I can look at that later but curious if you already did any investigation. |
|
@tarekgh I have sent you OS bug number on email. |
|
Another reason to revert #52992/#53119 is that it was not a correct fix in the first place. Since using System;
using System.Globalization;
CultureInfo.CurrentUICulture = CultureInfo.GetCultureInfo("es-MX");
// Outputs Spanish name: "Hora estándar del Pacífico"
Console.WriteLine(TimeZoneInfo.Local.StandardName);
CultureInfo.CurrentUICulture = CultureInfo.GetCultureInfo("en-US");
// Still outputs Spanish name: "Hora estándar del Pacífico"
Console.WriteLine(TimeZoneInfo.Local.StandardName); |
|
@AntonLapounov - that one is tracked by #50311. |
|
Great that we already have it filed. However, #50311 is not scheduled for 6.0 and I am not sure that the new Windows behavior:
is better than just sticking to English for the properties in question. Though the new behavior removed the difference between Windows and Linux/macOS, I would prefer implementing a correct fix. |
I don't think sticking to English is right. Usually, these properties are used in the UI and not returning them in the right language would be a concern. I think if someone requested these properties with a language that is not matching the cached language, we can re-read that value in that language (and would be ok to pay the cost for that scenario as I am not expecting this is main-stream scenario). We need to scope the work for what we can do in .NET 6.0 and what we can do later. note, that what @mattjohnsonpint did is a step in enhancing the whole story and it is better than none. Now, I am questioning if we can depend on ICU for that all the time (when we have ICU) and avoid calling Windows for such localized names. |
|
I meant sticking to the preferred UI language set by the OS (not necessary English) as we used to do before #52992/#53119.
That makes sense. |
|
Sorry for the delayed response. In general, the reason I was keen on having the display names not strictly tied to the default Windows UI language is because there was already logic in the Unix implementation that uses the CurrentUICulture. It doesn't make sense that the behavior is different on Windows than on Unix. Also, this has generally been a "gotcha" when localizing websites going way back to early ASP.NET - the only recourse being to use some other copy of the display names, such as provided by my TimeZoneNames library (see mattjohnsonpint/TimeZoneNames#50 and S.O. issues linked therein). It's a big step in the right direction to allow .NET to use whatever language packs are installed. It would be even better to have an option to use the ICU display names on Windows, but I believe that should be either opt-in to avoid conflict with existing behavior or very loudly announced with clear opt-out strategy. As for the memory corruption - I understand that calling |
|
@mattjohnsonpint I would like to fix this issue before we do anything for #50311. let's sync up offline. |
|
We occurred the same issue on August service update SDK: 3.1.118(runtime:3.1.18) on win-arm64. |
|
@vdanche I'm not sure it's the same issue, the callstack is different. |
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Change in initialization code of
TimeZoneInfointroduced by #52992 leads to AV or native heap corruption on Windows.Original issue description
Repro steps:
Install .NET 6 prevew 6 SDK-6.0.100-preview.6.21327.1(runtime-6.0.0-preview.6.21325.7) from https://github.com/dotnet/installer from Main branch
In CLI, execute below command.
mkdir ProC#
cd ProC#
dotnet new sln -o CSCLI
cd CSCLI
dotnet new console -o CSNC21App
dotnet new classlib -o CSNS20Lib
dotnet sln add CSNC21App\CSNC21App.csproj
dotnet sln add CSNS20Lib\CSNS20Lib.csproj
Expected Result:
No any errors
Actual Result:
.NET Host stop working.
Fatal error. System.AccessViolationException: Attempted to read or write protect
ed memory. This is often an indication that other memory is corrupt.
at Interop+Kernel32.GetFileMUIPath(UInt32, System.String, Char*, UInt32 ByRef
, Char*, UInt32 ByRef, UInt64 ByRef)
at System.TimeZoneInfo.GetFileMuiPath(System.String, System.Globalization.Cul
tureInfo)
at System.TimeZoneInfo.GetCachedFileMuiPath(System.String, System.Globalizati
on.CultureInfo)
at System.TimeZoneInfo.GetLocalizedNameByMuiNativeResource(System.String, Sys
tem.Globalization.CultureInfo)
at System.TimeZoneInfo.GetLocalizedNamesByRegistryKey(Internal.Win32.Registry
Key, System.String ByRef, System.String ByRef, System.String ByRef)
at System.TimeZoneInfo.TryGetTimeZoneFromLocalMachine(System.String, System.T
imeZoneInfo ByRef, System.Exception ByRef)
at System.TimeZoneInfo.TryGetTimeZoneFromLocalMachine(System.String, Boolean,
System.TimeZoneInfo ByRef, System.Exception ByRef, CachedData)
at System.TimeZoneInfo.TryGetTimeZoneUsingId(System.String, Boolean, System.T
imeZoneInfo ByRef, System.Exception ByRef, CachedData, Boolean)
at System.TimeZoneInfo.TryGetTimeZone(System.String, Boolean, System.TimeZone
Info ByRef, System.Exception ByRef, CachedData, Boolean)
at System.TimeZoneInfo.GetLocalTimeZone(CachedData)
at System.TimeZoneInfo+CachedData.CreateLocal()
at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(System.DateTime, Boolea
n ByRef)
at System.DateTime.get_Now()
at Microsoft.DotNet.Cli.Program.Main(System.String[])
Problem signature:
Problem Event Name: APPCRASH
Application Name: dotnet.exe
Application Version: 6.0.21.32507
Application Timestamp: 60d615d4
Fault Module Name: coreclr.dll
Fault Module Version: 6.0.21.32507
Fault Module Timestamp: 60d60cb9
Exception Code: c0000005
Exception Offset: 00000000001cb469
OS Version: 6.1.7601.2.1.0.256.27
Locale ID: 1033
Additional Information 1: ee7a
Additional Information 2: ee7aebb493adcdf2891586b392e6e5a5
Additional Information 3: c638
Additional Information 4: c638660efa7b5668612ea728d2ef2abb
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Note:
It's a inconsistent issue.
dotnet --info
The text was updated successfully, but these errors were encountered: