You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
May 9 21:11:41 server883 kernel: [218937.760135] .NET Server GC[1427719]: segfault at 8 ip 00007f7440ae835c sp 00007f74395bfdf0 error 6 #86183
We have seen it on multiple servers now running dotnet 7, we have not identified the issue on any servers running dotnet 6
We have identified one server where this is happening quote often:
What addition information could help with your investigation? For example, turn on a extra reporting, or we may be able to privately share a mini dump. If so please specify what you need and the correct way to enable and share privately.
Reproduction Steps
Unfortunately we have no steps identified to repro, but as seen above we do have a server experiencing the problem often.
Expected behavior
No segfaults
Actual behavior
segfaults occurring causing the container to crash and restart
Regression?
We have not seen this occur in dotnet 6
Known Workarounds
N/A
Update May 17th 2023: Can workaround this issue using the dotnet 6 GC in dotnet 7 by setting ENV VAR COMPlus_GCName=libclrgc.so. Note: this can only work in .NET 7 until such a moment when libclrgc.so is removed from the distribution
Configuration
mcr.microsoft.com/dotnet/sdk:7.0-jammy (7.0.203)
Ubuntu 20.04.6 LTS
x64
Other information
We know there has been big changes in GC in dotnet 7 compared to dotnet 6 and have yet to pin the problem any other change as of yet
Not on GC team, but they may ask you to try COMPlus_GCName=libclrgc.so. This will swap in the 6.0 GC - if it doesn't segfault, it's evidence the new GC is implicated.
yeah, if you could the env var that @danmoseley mentioned it would be great. if that doesn't repro, do you have a dump or at least a callstack that you could share with the default GC? and would it be possible to run with a private clrgc.dll if that would dramatically help with the investigation?
I am not familiar with what you mean by private clrgc.dll. A custom GC with addition debugging enabled? If the 2 stack traces above are not fruitful we can look at that next.
Let me know if you need something else,
Thanks for you help
verifyheap
Heap Segment Object Failure
4 7f0f48f5d698 7f103e404428 InvalidObjectReference Object 7f103e404428 has a bad member at offset cee8: 7f106210cf58
4 7f0f48fda068 7f12f3cf00a8 InvalidObjectReference Object 7f12f3cf00a8 has a bad member at offset 16ccd8: 7f12d8ce5568
8 7f0f48f6bec0 7f108f1a1348 InvalidMethodTable Object 7f108f1a1348 has an invalid method table 7f8647dad500
9 7f0f48f63070 7f105d891310 InvalidMethodTable Object 7f105d891310 has an invalid method table 7f8647dad6e8
13 7f0f48fad488 7f11fc906160 InvalidObjectReference Object 7f11fc906160 has a bad member at offset 16ccd8: 7f12d8ce5568
15 7f0f48f63d60 7f106210cf58 InvalidMethodTable Object 7f106210cf58 has an invalid method table 7f8647daced8
101,216,252 objects verified, 6 errors.
> dumpobj 7f103e404428
Name: System.Object[]
MethodTable: 00007f863e82a508
EEClass: 00007f863e82a480
Tracked Type: false
Size: 58640(0xe510) bytes
Array: Rank 1, Number of elements 7327, Type CLASS
Fields:
None
> dumpobj 7f12f3cf00a8
Name: Company.Product.ObjectModel.DTOParent.DTOChildren[]
MethodTable: 00007f864a75ea00
EEClass: 00007f863e82a480
Tracked Type: false
Size: 4194328(0x400018) bytes
Array: Rank 1, Number of elements 524288, Type CLASS
Fields:
None
> dumpobj 7f11fc906160
Name: Company.Product.ObjectModel.DTOParent.DTOChildren[]
MethodTable: 00007f864a75ea00
EEClass: 00007f863e82a480
Tracked Type: false
Size: 2097176(0x200018) bytes
Array: Rank 1, Number of elements 262144, Type CLASS
Fields:
None
hi @stefanschnabs, you could upload the dumps to a share and send details to my email (should be in my profile). Also since you seem to have been able to narrow down the issue to something around casting, is it possible to create a smaller repro?
Looks like corrupted heap issue. CastHelpers are some of the most called methods and thus tend to trip over GC holes more often. Seeing such crash in CastHelpers is typically (and sadly) not very helpful with figuring the root cause.
As we are approaching the release of .Net 8 and we are still dependent on the workaround of using COMPlus_GCName=libclrgc.so (.Net 6 GC) - will this workaround be compatible/available with .Net 8.0?
Thanks @mangod9, yes - we certainly want the problem fixed and run the latest 8.0 without falling back. But if the same issue we saw in .Net 7.0 is going to happen in .Net 8.0, it would be very important for us to enable the 6.0 GC behaviour until the root cause can be identified and fixed.
Hi @mangod9 we have captured a second full dump caused by GC. It looks like the channel that @baal2000 used to upload the first full dump has expired, see Secure File Exchange Case 2305190040006263 . Hopefully we can get this channel reopened and the second full dump uploaded.
sorry must have missed that message. I looked at the dump from 11/10, and I dont see any crash in it. Is it the right dump? I see most threads waiting and a few doing json deserialization with this stack:
Activity
danmoseley commentedon May 13, 2023
Not on GC team, but they may ask you to try
COMPlus_GCName=libclrgc.so. This will swap in the 6.0 GC - if it doesn't segfault, it's evidence the new GC is implicated.Maoni0 commentedon May 15, 2023
yeah, if you could the env var that @danmoseley mentioned it would be great. if that doesn't repro, do you have a dump or at least a callstack that you could share with the default GC? and would it be possible to run with a private clrgc.dll if that would dramatically help with the investigation?
stefanschnabs commentedon May 17, 2023
Hi @Maoni0,
We have not been able to reproduce the issue by:
COMPlus_GCName=libclrgc.so)We have been able to capture 2 native thread call stacks, hopefully this can help investigate
I am not familiar with what you mean by private clrgc.dll. A custom GC with addition debugging enabled? If the 2 stack traces above are not fruitful we can look at that next.
Let me know if you need something else,
Thanks for you help
Maoni0 commentedon May 17, 2023
the callstacks just say that GC detected a heap corruption but this is a very generic thing. is it possible to share a couple of dumps?
yes, by a private clrgc.dll (or in your case, libclrgc.so) I just meant we enable some instrumentation so it helps with debugging.
stefanschnabs commentedon May 17, 2023
How can we send you dump(s) privately using a secure channel?
stefanschnabs commentedon May 17, 2023
Have a couple other data points:
return new ABCClass() as T ?? new List<double>() as T;ended up with this stackbt: server883btallCast.txt
mangod9 commentedon May 17, 2023
hi @stefanschnabs, you could upload the dumps to a share and send details to my email (should be in my profile). Also since you seem to have been able to narrow down the issue to something around casting, is it possible to create a smaller repro?
@VSadov as fyi.
VSadov commentedon May 17, 2023
Looks like corrupted heap issue.
CastHelpersare some of the most called methods and thus tend to trip over GC holes more often. Seeing such crash inCastHelpersis typically (and sadly) not very helpful with figuring the root cause.jeffschwMSFT commentedon May 17, 2023
Our preference for receiving dumps is via the Visual Studio Developer Community. https://developercommunity.visualstudio.com/home
stefanschnabs commentedon May 24, 2023
As an update, the dump had been uploaded using Secure File Exchange
14 remaining items
pieter-venter commentedon Sep 15, 2023
As we are approaching the release of .Net 8 and we are still dependent on the workaround of using
COMPlus_GCName=libclrgc.so(.Net 6 GC) - will this workaround be compatible/available with .Net 8.0?mangod9 commentedon Sep 15, 2023
yeah it should still be supported in 8, though would be good to try without falling back to clrgc.
pieter-venter commentedon Sep 15, 2023
Thanks @mangod9, yes - we certainly want the problem fixed and run the latest 8.0 without falling back. But if the same issue we saw in .Net 7.0 is going to happen in .Net 8.0, it would be very important for us to enable the 6.0 GC behaviour until the root cause can be identified and fixed.
stefanschnabs commentedon Nov 1, 2023
Hi @mangod9 we have captured a second full dump caused by GC. It looks like the channel that @baal2000 used to upload the first full dump has expired, see Secure File Exchange Case 2305190040006263 . Hopefully we can get this channel reopened and the second full dump uploaded.
mangod9 commentedon Nov 2, 2023
hello @stefanschnabs, so you are still seeing the crashes with latest .NET 7 servicing build?
baal2000 commentedon Nov 3, 2023
@mangod9 It was 7.0.12 (7.0.13 is the latest security patch as of Oct 24)
vs. May 12 report
baal2000 commentedon Nov 18, 2023
@mangod9
The full process dump generated after GC segfault had been uploaded on Nov 10.
stefanschnabs commentedon Nov 20, 2023
If its not clear, @baal2000 is talking about the second full dump, so you can look for patterns in them.
mangod9 commentedon Nov 20, 2023
sorry must have missed that message. I looked at the dump from 11/10, and I dont see any crash in it. Is it the right dump? I see most threads waiting and a few doing json deserialization with this stack:
baal2000 commentedon Nov 20, 2023
@mangod9
Sorry we have been under impression this is the correct dump because it was recorded right after the GC segfault exception.
Later I have loaded the dump into lldb and could not find an exception there. The main thread's stop reason = signal SIGSTOP.
Not sure what it really means and what triggered the dump collection but agree the dump is probably not useful.
stefanschnabs commentedon Apr 30, 2024
Hi @mangod9 @Maoni0 @VSadov @jeffschwMSFT @danmoseley, We have not seen this issue on .NET 8.
I think we can close out this issue, thanks all for your help