daohualiuxiang
/
dotnet
mirror of https://github.com/microsoft/dotnet.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #613 from leculver/master 

Add known issue for 470006 - GC large object crashes
pull/616/head
Lee Culver 2018-02-06 13:30:47 -08:00 committed by GitHub
parent 28dc8e37a2 97ec633bc6
commit 9a1e233aa6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
releases/net471/KnownIssues/470006-GC Crashes with high rate of large object allocation.md 100644
View File

@ -0,0 +1,34 @@
# Rare crashes can occur when background GC is enabled in applications that allocate and free large objects at a high rate
## Symptoms
When background GC is enabled, an application running on .NET Framework 4.7.1 experiences
intermittent crashes that did not occur when running on other .NET Framework versions.
## Cause
.NET Framework 4.7.1 includes changes that improve background GC performance.
Because of these changes, a rare combination of factors can cause the background GC
to reclaim a large object while the program is still using it.
## Impact
This problem impacts applications that run with the background GC enabled and that also allocate
and free large objects at a high rate. As described in the article [Fundamentals of Garbage Collection](https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#the-managed-heap),
a large object is any object that is 85,000 bytes or larger in size.
This problem is rare, and is more likely to occur when running on the x86 version of the
.NET Framework than when running on the x64 version of the 4.7.1 .NET Framework.
## Workarounds
The most practical workaround is to disable the background GC by setting the enabled attribute of the [<gcConcurrent> element](https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcconcurrent-element) in the
<runtime> section of your application configuration file to false.
The only other workaround is to change the application to allocate and free large objects
at a much lower rate.
## Resolution
This problem is fixed in [.NET Framework 4.7.2](http://go.microsoft.com/fwlink/?LinkId=863281).

1
releases/net471/dotnet471-known-issues.md
View File

@ -4,6 +4,7 @@
This document lists the known issues that you may experience after you install the Microsoft .NET Framework 4.7.1.
## Product issues for the .NET Framework 4.7.1
- [470006 - GC - Rare crashes can occur when background GC is enabled in applications that allocate and free large objects at a high rate](https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/470006-GC%20Crashes%20with%20high%20rate%20of%20large%20object%20allocation.md)
- [479874 - WPF - Touch Stops Working After Rapid/Prolonged Use Of Popups](https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/479874-WPF%20Touch%20Stops%20Working%20After%20Prolonged%20Use%20of%20Popups.md)
- [481090 - WPF - Touch generates a NullReferenceException in WispLogic.ProcessInputReport](https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/481090-WPF%20Touch%20generates%20NullReferenceException%20in%20ProcessInputReport.md)
- [489937 - WPF - Touch/Stylus Generates AccessViolations and Heap Corruption in GetPenEventMultiple](https://github.com/Microsoft/dotnet/blob/master/releases/net471/KnownIssues/489937-WPF%20Touch%20and%20Stylus%20AccessViolation%20in%20GetPenEventMultiple.md)