[Android] App crashing with condition `xref_count == xref_index' not met

[kklose23]

Description

This is happening when using shell navigation to navigate to a bunch of pages. Unfortunately I was unable to reproduce it on a simpler project to post. So I'm uncertain exactly what's causing this. However, it was working on MAUI version 8.0.40 and broke on subsequent versions.

I was able to reproduce on the Android emulator

Others have posted about this as well:
dotnet/maui#23827
dotnet/maui#23634
dotnet/maui#23826

Steps to Reproduce

See description

Link to public reproduction project repository

No response

Version with bug

8.0.60 SR6

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.40 SR5

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

[namix.mobileapp] * Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1174, condition `xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 1101 but we added 1096 xrefs
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 8651 (namix.mobileapp), pid 8651 (namix.mobileapp)

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• [ANR][Android] crashes when navigating (#18331), similarity score: 0.77

Closed similar issues:

• Support navigating to a new shell via NavigationPage (#23356), similarity score: 0.81
• Crash - Android condition `xref_count == xref_index' not met, function:processing_build_callback_data (#23827), similarity score: 0.81
• Android crash on navigate back from tab 2 without Shell (#15687), similarity score: 0.78
• Android App crashes on startup (#20176), similarity score: 0.78

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[Redth]

@jonathanpeppers could you or someone on Android team have a look?

[jonathanpeppers]

I don't think this is related to dotnet/android.

It says it's on this line: src/mono/mono/metadata/sgen-tarjan-bridge.c:1174

If I look on the release/8.0 branch might be this g_assertf():

• runtime/src/mono/mono/metadata/sgen-tarjan-bridge.c

  Line 1174 in ed13b35

  g_assertf (xref_count == xref_index, "xref_count is %d but we added %d xrefs", xref_count, xref_index);

I think we can transfer to runtime.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

@BrzVlad could you please take a look?

[BrzVlad]

I've seen reports for crashes like this for a few years now, ever since we switched to the tarjan bridge implementation as default, but we havent yet received a repro project so that we can investigate. The recommended solution is to use the new bridge by adding this to the environment vars: MONO_GC_PARAMS=bridge-implementation=new.

[Pmr-precure]

We are having the same issue at the moment, version 8.0.91

[kklose23]

We were able to fix the issue using the suggestion above. We added an Environment.txt file with the following:
MONO_GC_PARAMS=bridge-implementation=new

And added this to the project file:

  <ItemGroup>
    <AndroidEnvironment Include="Platforms\Android\Environment.txt" />
  </ItemGroup>

[pubudulk]

We were able to fix the issue using the suggestion above. We added an Environment.txt file with the following: MONO_GC_PARAMS=bridge-implementation=new

And added this to the project file:

  <ItemGroup>
    <AndroidEnvironment Include="Platforms\Android\Environment.txt" />
  </ItemGroup>

Are you suggesting to use the Environment.txt file approach rather than code approach mentioned below? We tried setting the bridge implementation like below but it didnt work.
Java.Lang.JavaSystem.SetProperty("MONO_GC_PARAMS", "bridge-implementation=new,nursery-size=128‌​m,soft-heap-limit=51‌​2m")

[andersondamasio]

Also having this issue
Version .Net 9 Maui 9.0.40

/__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 137 but we added 133 xrefs

The problem arises when browsing some pages of the application for a while.

In the .Net 8 version this same problem did not seem to happen.

The application closes without throwing debugger-level exceptions.

Among the suggestions, is there any appropriate action to try to resolve the problem?

[filipnavara]

I have a pretty good idea why is this happening.

This code path can introduce duplicates into the color->other_colors array:

runtime/src/mono/mono/metadata/sgen-tarjan-bridge.c

Lines 795 to 798 in b658cd2

	// Maybe we should make sure we are not adding duplicates here. It is not really a problem
	// since we will get rid of duplicates before submitting the SCCs to the client in gather_xrefs
	if (color_data)
	add_other_colors (color_data, &other->xrefs);

Then we get to the code that counts xref_count:

runtime/src/mono/mono/metadata/sgen-tarjan-bridge.c

Lines 1101 to 1114 in b658cd2

	// Eliminate non-visible SCCs from the SCC list and redistribute xrefs
	for (cur = root_color_bucket; cur; cur = cur->next) {
	ColorData *cd;
	for (cd = &cur->data [0]; cd < cur->next_data; ++cd) {
	if (!color_visible_to_client (cd))
	continue;
	color_merge_array_empty ();
	gather_xrefs (cd);
	reset_xrefs (cd);
	dyn_array_ptr_set_all (&cd->other_colors, &color_merge_array);
	xref_count += dyn_array_ptr_size (&cd->other_colors);
	}
	}

It uses the color_visible_to_client helper method which in turn calls bridgeless_color_is_heavy:

runtime/src/mono/mono/metadata/sgen-tarjan-bridge.c

Lines 131 to 139 in b658cd2

	static gboolean
	bridgeless_color_is_heavy (ColorData *data) {
	if (disable_non_bridge_scc)
	return FALSE;
	int fanin = data->incoming_colors;
	int fanout = dyn_array_ptr_size (&data->other_colors);
	return fanin > HEAVY_REFS_MIN && fanout > HEAVY_REFS_MIN
	&& fanin*fanout >= HEAVY_COMBINED_REFS_MIN;
	}

The fanout metric is computed from the count of other_colors which contain duplicates. Once the references are gathered with gather_xrefs they get deduplicated. This can change the number of fanout nodes just enough that it no longer satisfies the "heavy" property. We still increase the xref_count but in the second loop that iterates over the same data it will get skipped and result in a mismatch:

runtime/src/mono/mono/metadata/sgen-tarjan-bridge.c

Lines 1126 to 1130 in b658cd2

	for (cur = root_color_bucket; cur; cur = cur->next) {
	ColorData *src;
	for (src = &cur->data [0]; src < cur->next_data; ++src) {
	if (!color_visible_to_client (src))
	continue;

[filipnavara]

I managed to reproduce the scenario in my synthetic tests: https://github.com/filipnavara/runtime/tree/standalone-gc-bridge-test

https://github.com/filipnavara/runtime/blob/1130986fa6df85c13691cefe3b57828bee8a5b25/src/mono/tests/GCBridge/main.c#L106-L127

Presumably it can be further simplified.

[filipnavara]

Repro:

Archive.zip

[bcaceiro]

I am also facing this:

• Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 572 but we added 563 xrefs [monodroid] * Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 572 but we added 563 xrefs
  [monodroid] Abort at mono-log-adapter.cc:46:3 ('static void xamarin::android::internal::MonodroidRuntime::mono_log_handler(const char *, const char *, const char *, mono_bool, void *)')

Unfortunatly I don't have a simplified repro

Using:
.NET MAUI 9.0.5

Installed Workload Id      Manifest Version       Installation Source
---------------------------------------------------------------------------------------
android                    35.0.39/9.0.100        VS 17.14.35806.103, VS 17.13.35828.75
ios                        18.2.9180/9.0.100      VS 17.14.35806.103, VS 17.13.35828.75
maccatalyst                18.2.9180/9.0.100      VS 17.14.35806.103, VS 17.13.35828.75
maui-windows               9.0.14/9.0.100         VS 17.14.35806.103, VS 17.13.35828.75

[thedee]

Getting this issue also on Android. Only the debug window shows any clue on what happened when the app crashed:

[] * Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition `xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 3913 but we added 3901 xrefs
[monodroid] * Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition `xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 3913 but we added 3901 xrefs
[monodroid] Abort at mono-log-adapter.cc:46:3 ('static void xamarin::android::internal::MonodroidRuntime::mono_log_handler(const char *, const char *, const char *, mono_bool, void *)')
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 17967 (.NET TP Worker), pid 13448 (xxxxxxx.xxx)

[filipnavara]

A fix is being worked on. Until it is released, you can use the workaround in #106410 (comment).

[thedee]

A fix is being worked on. Until it is released, you can use the workaround in #106410 (comment).

This does not fix the issue. I added it and it still crashes.

[filipnavara]

This does not fix the issue. I added it and it still crashes.

It literally doesn't enter the problematic code path if the option is applied, so either you are experiencing a different issue or the workaround was not applied correctly. Can you post the things that you added to your project file and the part of the crash log containing the "assert" message?

[MartinMilan]

This does not fix the issue. I added it and it still crashes.

It worked for me. Did you clean and build after?

[thedee]

This does not fix the issue. I added it and it still crashes.

It literally doesn't enter the problematic code path if the option is applied, so either you are experiencing a different issue or the workaround was not applied correctly. Can you post the things that you added to your project file and the part of the crash log containing the "assert" message?

I added this to my csproj file:

<ItemGroup>
	<AndroidEnvironment Include="Platforms\Android\Environment.txt" />
</ItemGroup>

And then I added the Environment.txt file with content of:
MONO_GC_PARAMS=bridge-implementation=new

I also did a clean/rebuild and still no luck. Below is what the latest output window shows:

* Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition `xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 1375 but we added 1363 xrefs
[monodroid] * Assertion at /__w/1/s/src/mono/mono/metadata/sgen-tarjan-bridge.c:1176, condition `xref_count == xref_index' not met, function:processing_build_callback_data, xref_count is 1375 but we added 1363 xrefs
[monodroid] Abort at mono-log-adapter.cc:46:3 ('static void xamarin::android::internal::MonodroidRuntime::mono_log_handler(const char *, const char *, const char *, mono_bool, void *)')
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 21831 (tindustries.rpt), pid 21831 (xxxxxxx.xxx)

[BrzVlad]

I remember there being some issues with passing env variables to android app. @jonpryor I think you took a look at this not too long ago, do you have some more info ?

[filipnavara]

That does look reasonable but apparently the environment variable is not set to the new value. Can you verify that you don't have some other AndroidEnvironment item that overrides the same variable? Also, you can produce a msbuild.binlog file by running the build from command line with dotnet build ... -bl. If you share it, we can look into some possible culprits.

[thedee]

In my code I added this in the App.xaml.cs:

string gcParams = Environment.GetEnvironmentVariable("MONO_GC_PARAMS");
Console.WriteLine($"MONO_GC_PARAMS: {gcParams ?? "Not set"}");

and it returns this:
[DOTNET] MONO_GC_PARAMS: major=marksweep-conc

So it seems to me the environment variable is not working. I did a search to see if it is being set anywhere else and it isn't.

[akoeplinger]

This is probably dotnet/android#9701. Someone there mentioned <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk> as a workaround but that is a bit weird since it should be the default in Release configuration.

[thedee]

This is probably dotnet/android#9701. Someone there mentioned <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk> as a workaround but that is a bit weird since it should be the default in Release configufation.

So when I added this:

<PropertyGroup Condition="$(TargetFramework.Contains('-android'))">
	<EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
</PropertyGroup>

My code now shows this:
[DOTNET] MONO_GC_PARAMS: bridge-implementation=new

Debugging seems to be running better now without crashing but I am still testing. It was really slow starting the debugger tho.

[akoeplinger]

It was really slow starting the debugger tho.

yes that's expected. This disables the Fast Deployment feature which means a lot more data needs to be packed into the .apk