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

kklose23 · 2024-08-14T18:26:44Z

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 · 2024-08-14T18:27:11Z

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 · 2024-08-14T19:09:46Z

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

jonathanpeppers · 2024-08-14T19:13:22Z

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 · 2024-08-14T19:14:14Z

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

vitek-karas · 2024-08-15T09:50:10Z

@BrzVlad could you please take a look?

BrzVlad · 2024-08-15T15:19:48Z

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 · 2024-10-03T09:31:16Z

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

kklose23 · 2024-10-03T13:13:23Z

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 · 2024-10-08T11:16:31Z

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")

Follows the recommendation from dotnet/runtime#106410 (comment)

andersondamasio · 2025-02-17T22:44:15Z

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 · 2025-03-02T15:52:32Z

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 · 2025-03-02T16:56:39Z

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 · 2025-03-02T18:06:51Z

Repro:

Archive.zip

jonathanpeppers transferred this issue from dotnet/maui Aug 14, 2024

dotnet-issue-labeler bot added the needs-area-label label Aug 14, 2024

dotnet-policy-service bot added the untriaged label Aug 14, 2024

jonathanpeppers added the area-GC-mono label Aug 14, 2024

vitek-karas assigned BrzVlad Aug 15, 2024

vitek-karas added this to the 9.0.0 milestone Aug 15, 2024

dotnet-policy-service bot removed the untriaged label Aug 15, 2024

teo-tsirpanis removed the needs-area-label label Aug 16, 2024

mangod9 modified the milestones: 9.0.0, Future Aug 28, 2024

BrzVlad mentioned this issue Oct 8, 2024

sgen-tarjan-bridge.c crash dotnet/android#9377

Closed

jeromelaban mentioned this issue Nov 18, 2024

[Droid] Fatal crash with unknown reason unoplatform/uno#17512

Closed

jeromelaban mentioned this issue Nov 28, 2024

Critical GREF Accumulation Issue with StaticLayout and String in Uno Platform on Android unoplatform/uno#18951

Open

BrzVlad mentioned this issue Jan 20, 2025

# Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr ************ in tid **** (SGen worker) #105389

Open

daniele-calanchi mentioned this issue Jan 22, 2025

Compiler doesn't elaborate environment variable MONO_GC_PARAMS dotnet/android#9701

Open

jeromelaban mentioned this issue Jan 29, 2025

fix: Use "new" android bridge by default unoplatform/uno.templates#1203

Merged

This was referenced Mar 2, 2025

[.NET 8] Android crash at mono_gc_wbarrier_generic_store_internal #109461

Open

Fix an edge case in the Tarjan GC bridge that leads to losing xref information #112825

Open

filipnavara added a commit to filipnavara/runtime that referenced this issue Mar 2, 2025

Add repro for dotnet#106410

d25956c

filipnavara linked a pull request Mar 2, 2025 that will close this issue

[SGen/Tarjan] Handle edge case with node heaviness changing due to deduplication #113044

Open

dotnet-policy-service bot added the in-pr label Mar 2, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

kklose23 commented Aug 14, 2024

github-actions bot commented Aug 14, 2024

Redth commented Aug 14, 2024

jonathanpeppers commented Aug 14, 2024

dotnet-policy-service bot commented Aug 14, 2024

vitek-karas commented Aug 15, 2024

BrzVlad commented Aug 15, 2024

Pmr-precure commented Oct 3, 2024 •

edited

Loading

kklose23 commented Oct 3, 2024

pubudulk commented Oct 8, 2024

andersondamasio commented Feb 17, 2025

filipnavara commented Mar 2, 2025

filipnavara commented Mar 2, 2025 •

edited

Loading

filipnavara commented Mar 2, 2025

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

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

Comments

kklose23 commented Aug 14, 2024

Description

Steps to Reproduce

Link to public reproduction project repository

Version with bug

Is this a regression from previous behavior?

Last version that worked well

Affected platforms

Affected platform versions

Did you find any workaround?

Relevant log output

github-actions bot commented Aug 14, 2024

Open similar issues:

Closed similar issues:

Redth commented Aug 14, 2024

jonathanpeppers commented Aug 14, 2024

dotnet-policy-service bot commented Aug 14, 2024

vitek-karas commented Aug 15, 2024

BrzVlad commented Aug 15, 2024

Pmr-precure commented Oct 3, 2024 • edited Loading

kklose23 commented Oct 3, 2024

pubudulk commented Oct 8, 2024

andersondamasio commented Feb 17, 2025

filipnavara commented Mar 2, 2025

filipnavara commented Mar 2, 2025 • edited Loading

filipnavara commented Mar 2, 2025

Pmr-precure commented Oct 3, 2024 •

edited

Loading

filipnavara commented Mar 2, 2025 •

edited

Loading