Crash related to GC: help interpreting stacktrace #97661
Labels
Comments
ghost
added
the
dotnet-issue-labeler
bot
added
the
needs-area-label
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsFrom @charlesroddie on Mon, 29 Jan 2024 17:25:32 GMT Our NativeAOT-compiled ios app crashes after a certain period of time from one of the pages, with a crash report indicating GC issues. We would like help on how to diagnose this. We understand very little of it beyond the fact that System.Linq is involved (we use almost no System.Linq but we use realm which uses it) and GC. Is there any other info we should be getting? Steps to ReproduceGet the Summatic IOS app from testflight or the Store. Navigate to a question. Wait 20-30mins. Expected BehaviorNothing happens Actual BehaviorThe app crashes. This crash is not registered on AppCenter and does not trigger EnvironmentVersion informationBuild LogsAvailable if useful Symbolicated crash reportExample Project (If Possible)Our project could be shared privately on request. Copied from original issue xamarin/xamarin-macios#19950
|
jkotas
added
os-ios
|
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos Issue DetailsFrom @charlesroddie on Mon, 29 Jan 2024 17:25:32 GMT Our NativeAOT-compiled ios app crashes after a certain period of time from one of the pages, with a crash report indicating GC issues. We would like help on how to diagnose this. We understand very little of it beyond the fact that System.Linq is involved (we use almost no System.Linq but we use realm which uses it) and GC. Is there any other info we should be getting? Steps to ReproduceGet the Summatic IOS app from testflight or the Store. Navigate to a question. Wait 20-30mins. Expected BehaviorNothing happens Actual BehaviorThe app crashes. This crash is not registered on AppCenter and does not trigger EnvironmentVersion informationBuild LogsAvailable if useful Symbolicated crash reportExample Project (If Possible)Our project could be shared privately on request. Copied from original issue xamarin/xamarin-macios#19950
|
|
This is crashing in FlushProcessWriteBuffers introduced in https://github.com/dotnet/runtime/pull/44670/files#diff-236bca3ea8ce55b54c55c47ab9d21a4db9596eb3fbc6052565a81a2ebb3ee73fR3466 This code is iterating over all threads in the process and asking for registers of each thread. The first thing to find out is the thread that it is crashing on. cc @janvorli |
|
Looking at the log above, it seem the problem is a stack overflow. It says:
So the access is inside of the stack guard. |
|
I presume the default secondary thread stack size on iOS/iPadOS matches macOS and is 512kb as well |
|
Is this looking like a dotnet/runtime bug? Is there any other info we could find that would help? It's interesting that are two other reports recently (see linked item immediately above) that also involved ios, gc, release mode, System.Linq, and write barriers of some form, although they were on MonoAOT not NativeAOT. Probably the bug will show if you run System.Linq tests on ios nativeaot (tracked here: #81075) Since all these reports are very recent, maybe there was a recent update in ios itself that changed something? (I went back to an old testflight from Nov 17th and the bug was there on that version which supports this theory.) We got this exception previously via some Realm method calling some System.Linq method and when we adjusted the Realm code we got it via CSharpMath calling System.Linq. So System.Linq seems to be involved in all cases. |
Based on #97661 (comment), this looks like a stackoverflow in the app main thread. Can you check the full stack and stack size of the crashing thread?
These two other reports do not look related to this issue.
System.Linq is a lot of complicated code. It is not unusual for System.Linq to hit bugs that no other code hits. |
|
The error reporting for stackoverflow is not implemented in native AOT (tracked byhttps://github.com//issues/82334). Better error reporting would not fix the crash that you are hitting. It would just a produce a better error message for it if it is a stackoverflow. |
|
We weren't able to get any useful diagnostics such as a full stack or stack size, but through trial and error we believe we tracked this down to use of SKMetalView (mono/SkiaSharp#2762) and we confirmed the issue is unrelated to NativeAOT. Thanks for the advice here. @rolfbjarne can you close this issue? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
From @charlesroddie on Mon, 29 Jan 2024 17:25:32 GMT
Our NativeAOT-compiled ios app crashes after a certain period of time from one of the pages, with a crash report indicating GC issues. We would like help on how to diagnose this. We understand very little of it beyond the fact that System.Linq is involved (we use almost no System.Linq but we use realm which uses it) and GC. Is there any other info we should be getting?
Steps to Reproduce
Get the Summatic IOS app from testflight or the Store. Navigate to a question. Wait 20-30mins.
Expected Behavior
Nothing happens
Actual Behavior
The app crashes. This crash is not registered on AppCenter and does not trigger
Runtime.MarshalManagedExceptionorRuntime.MarshalObjectiveCExceptionorAppDomain.CurrentDomain.UnhandledExceptionorTaskScheduler.UnobservedTaskException. There is a crash report on Testflight, attached below.Environment
Version information
Build Logs
Available if useful
Symbolicated crash report
Example Project (If Possible)
Our project could be shared privately on request.
Copied from original issue xamarin/xamarin-macios#19950
The text was updated successfully, but these errors were encountered: