Assertion at /__w/1/s/src/mono/mono/metadata/loader.c:1638, condition `id <= GPOINTER_TO_UINT (*data)' not met

[crui3er]

Description

I am profiling a hybrid blazor app on Android. I follow to instuction https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/tracing.md If I move app to background and then bring it back, then stopping trace recording fails with an error below, app crashes.

[00:00:00:46]   Recording trace 1,3945   (MB)
Press <Enter> or <Ctrl+C> to exit...
[ERROR] Microsoft.Diagnostics.NETCore.Client.ServerNotAvailableException: Could not send Stop command. The target process may have exited.
   at Microsoft.Diagnostics.NETCore.Client.EventPipeSession.Stop() in /_/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/EventPipeSession.cs:line 61
   at Microsoft.Diagnostics.Tools.Trace.CollectCommandHandler.Collect(CancellationToken ct, IConsole console, Int32 processId, FileInfo output, UInt32 buffersize, String providers, String profile, TraceFileFormat format, TimeSpan duration, String clrevents, String clreventlevel, String name, String diagnosticPort, Boolean showchildio, Boolean resumeRuntime) in /_/src/Tools/dotnet-trace/CommandLine/Commands/CollectCommand.cs:line 321

In android log I found an error with failed assertion (see title) that causes app crash. In past (I used .net 7.0.0 workload) I had similar issue sometimes during recording startup traces, but i could workaround it with doing an extra attemt. But moving app to background and back to foreground make it crash every time.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.0-rc.1.9171

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

10-18 21:46:31.142	Xiaomi Redmi Note 9 Pro	Error	15057	.actual.dev.ap	* Assertion at /__w/1/s/src/mono/mono/metadata/loader.c:1638, condition `id <= GPOINTER_TO_UINT (*data)' not met
10-18 21:46:31.547	Xiaomi Redmi Note 9 Pro	Error	15057	libc	Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 15079 (Thread-2), pid 15057 (.actual.dev.app)

[PureWeen]

@jonathanpeppers thoughts?

[jonathanpeppers]

• Assertion at /__w/1/s/src/mono/mono/metadata/loader.c:1638, condition `id <= GPOINTER_TO_UINT (*data)' not met

Seems like the assertion is here (looking at release/7.0 branch):

https://github.com/dotnet/runtime/blob/bad10ca2c460086992118086b67f3e759532fb27/src/mono/mono/metadata/loader.c#L1638

I think we can move to dotnet/runtime.

[crui3er]

Hi. Any chance somebody can help with this?

[tommcdon]

Adding @davmason @mdh1418 for thoughts cc @lateralusX

[lateralusX]

Probably need local repro or callstack from the assert since its in a generic loader method, not directly called by EventPipe, having that said, EventPipe iterates through types when emitting rundown events, so if anything has been released/unloaded as part of moving app to background and then to foreground without being fully reflected in JIT or interpreter tables, that could cause side effects. We also have a fix for a rare race condition in the JIT table currently in main, that table gets enumerated by EventPipe during shutdown, so if there are other activities triggered in the app that cause a lot of traffic on the JIT table while we iterate it (ending up growing it) we could hit issues trying to get additional metadata about a type in the table, https://github.com/dotnet/runtime/pull/96771. This is a rare race condition that I personally have not seen it (either live or on CI) so it shouldn't be that common, but just wanted to mention it since it happens during rundown and if it does happen will cause issues around the method/type handling.

[mdh1418]

I just traced a default maui app (built with dotnet 8.0.300-preview.24107.20) on both Android emulator and Android device with dotnet-dsrouter and dotnet-trace version 8.0.510801. I didn't hit any crashes when moving that app to background and bringing it back to foreground.

@crui3er would you happen to have a sample app that reproduces the issue that you wouldn't mind sharing, since it doesn't seem to be occurring in a default scenario?

edit: Also tried tracing the default maui-blazor app on android device

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[crui3er]

I can't provide sample project. Template maui app did cause this issue. But our app is quite big and I can't figure out when this issue appeared. My last test showed that I can successfully collect a trace. May be updating tools or sdk helped with it. dotnet-dsrouter 8.0.510501 dotnet-trace 8.0.510501 android (workload) 34.0.52/8.0.100 But for android we currently stick to runtime 8.0.0 since there is regression in 8.0.1 preventing debugging https://github.com/dotnet/runtime/issues/96804#issuecomment-1897432561

[mdh1418]

Thank you for checking that the tools work for your workflow now! It seems like that issue is fixed, and it looks like dotnet sdk 8.0.200 is out now https://dotnet.microsoft.com/en-us/download/dotnet if you wanted to try that out.

I'll close this issue as it may have been fixed, and if we see the issue pop up again we can reopen this.