[MarshalMethods] .NET 9 Android crash: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7228361bf07b in tid 4437 (.NET TP Worker)

[mfeingol]

Description

Not a lot to go on at the moment, but maybe this is a known issue? I'm porting my app to .NET 9 and this happens when I render a Google map with a specific set of polylines and markers. The same thing works fine with .NET 8 and in debug mode on .NET 9.

Steps to Reproduce

TBD. Likely will need access to my app and to a very specific data set.

Link to public reproduction project repository

No response

Version with bug

9.0.10 SR1

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.93 SR9.3

Affected platforms

Android

Affected platform versions

Android 14

Did you find any workaround?

No

Relevant log output

Time	Device Name	Type	PID	Tag	Message
	pixel_7_pro_-_api_34	Error	4338	libc	Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7228361bf07b in tid 4437 (.NET TP Worker), pid 4338 (ckroads.android)

[Ying-6]

Hi @mfeingol, could you provide us with a sample project so we can investigate it further? Looking forward to your reply!

[mfeingol]

@Ying-6: thanks for following up. I have repro steps ready for someone who can build my app in release mode and deploy to an Android emulator or device. Who should I add to my project?

[Ying-6]

Hi @mfeingol, could you add me(@Ying-6 ) to your project permissions so that I can get access to your project?

[mfeingol]

@Ying-6: added you as a collaborator.

You'll want the net9-maui branch. Open the .sln file in VS 2022. Build Sideroads.Maui for release. Deploy to emulator. Then follow these steps:

1. Run the app
2. Say OK to the prompts
3. Tap on the | menu in the Trips tab of the Trips page and select Import Trip
4. Select this file: https://1drv.ms/u/s!ArS4HFRp-_RCmtctQn1iimkU_lJJAQ?e=aosQvo
5. Once imported, tap on the "Pre-Thanksgiving" trip to select it
6. From the Calendar page, tap on Sunday Nov 24th to open the expander
7. Tap on the green "Canyoneer Dothraki" activity
8. Say OK to a location prompt if needed
9. Tap on the Map tab
10. Observe the sigsegv crash

[Ying-6]

This issue has been verified using Visual Studio 17.13 Preview 1 (9.0.12 & 9.0.10). Can repro this issue on Android platform. And 8.0.100 works fine.

[mfeingol]

Thanks, @Ying-6. Any thoughts around root cause or workaround?

[PureWeen]

Can you attach a logcat file with your crash?
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/debugging/android-debug-log?tabs=windows

[mfeingol]

logcat.txt

@PureWeen: here's a logcat file. Not a lot in there... the most relevant line is:

pixel_7_pro_-_api_34 Info 356 Zygote Process 5713 exited due to signal 11 (Segmentation fault)

[jonpryor]

@mfeingol: it looks like the logcat.txt you provided was copied and pasted from the Visual Studio Device Log.

Could you instead try capturing it from the command line?

1. Click Tools > Android > Android Adb Command Prompt…

   

2. Then run:

   adb logcat > logcat.txt

3. Run your app, cause it to crash.

4. Return to the Command Prompt from (1), type Ctrl+C, then upload the logcat.txt from (2).

The resulting logcat.txt should contain significantly more information.

[mfeingol]

@jonpryor: apologies. Here is that file.logcat.txt

[jonpryor]

@mfeingol: looks like I wasn't entirely correct: there still isn't the stack trace that I expected to see.

Is this app debuggable? Is this a Debug or Release config build, and do you set ApplicationAttribute.Debuggable or explicitly set //application/@android:debuggable in your AndroidManifest.xml?

IIRC, to get full stack traces in logcat, the app must be "debuggable", as per the final AndroidManifest.xml. (By default, Debug configuration builds are debuggable, while Release configuration builds are not debuggable. This can be controlled by various MSBuild properties, C# custom attributes, and by explicitly editing AndroidManifest.xml.)

One thing that doesn't look quite right in the most recent logcat:

4681  4681 W ckroads.android: Unexpected CPU variant for x86: x86_64.

which suggests you're using an x86 emulator, but trying to launch an x86_64 app? Though I'd expect that scenario to fail far earlier, so I'm not entirely certain here -- maybe this message should be ignored? -- and subsequent messages show that it is looking at x86_64 data:

4681 4681 D nativeloader: Configuring clns-7 for other apk /data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/base.apk:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/split_config.en.apk:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/split_config.x86_64.apk:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/split_config.xxxhdpi.apk. target_sdk_version=35, uses_libraries=, library_path=/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/lib/x86_64:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/base.apk!/lib/x86_64:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/split_config.en.apk!/lib/x86_64:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/split_config.x86_64.apk!/lib/x86_64:/data/app/~~Fel7rDrL373ioa5e3WmyOA==/com.backroads.android-LxkEPlIvoam56nvWe4B90Q==/sp

Note split_config.x86_64.apk, so it's certainly using x86_64 data.

I also find the following message concerning, but I don't know if it's meaningful or not:

4681  4681 E ckroads.android: Not starting debugger since process cannot load the jdwp agent.

@mfeingol: Please verify that your app is debuggable (Debug config build, not setting [assembly:Application(Debuggable=false)] or setting <application android:debuggable="false" /> in AndroidManifest.xml), and try again.

[mfeingol]

@jonpryor: I didn't have Debuggable=false explicity set anywhere, but after setting <application android:debuggable="true" /> in my manifest there's a bit more information in the log:

12-09 09:35:40.034  5894  5894 F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x0000763f1c9d901e
12-09 09:35:40.035  5894  5894 F DEBUG   :     rax 0000763f1c9d8fa2  rbx 000000000000008c  rcx 0000000000000000  rdx 000000000000008c
12-09 09:35:40.035  5894  5894 F DEBUG   :     r8  ffff89c124bc406a  r9  0000763f1c9d9000  r10 0000000000000000  r11 0000763e600338e0
12-09 09:35:40.036  5894  5894 F DEBUG   :     r12 0000000000011106  r13 00007640bca05c90  r14 000000004159d000  r15 000076404c972c70
12-09 09:35:40.036  5894  5894 F DEBUG   :     rdi 0000763f1c9d8fa2  rsi 000000004159d00c
12-09 09:35:40.036  5894  5894 F DEBUG   :     rbp 0000000000000000  rsp 0000763e4df48640  rip 00007641706f4d3b
12-09 09:35:40.036  5894  5894 F DEBUG   : 3 total frames
12-09 09:35:40.037  5894  5894 F DEBUG   : backtrace:
12-09 09:35:40.037  5894  5894 F DEBUG   :       #00 pc 0000000000054d3b  /apex/com.android.runtime/lib64/bionic/libc.so (memcpy+1019) (BuildId: fa337969c798946280caa45e2d71a2e7)
12-09 09:35:40.037  5894  5894 F DEBUG   :       dotnet/maui#1 pc 000000000000008c  <unknown>
12-09 09:35:40.037  5894  5894 F DEBUG   :       dotnet/maui#2 pc 00000000006c3cd4  /apex/com.android.art/lib64/libart.so (art::JNI<true>::GetByteArrayRegion(_JNIEnv*, _jbyteArray*, int, int, signed char*)+884) (BuildId: b6dc79e02101ea00827a35a55ab6597a)

logcat.txt

Both the app and the emulator image are x64 as far as I can tell.

Let me know if you want to cut out the middleman here and I can give you access to my project. Repro instructions are above.

[mfeingol]

It looks like I'm hitting the same issue as dotnet/maui#16514 and sure enough this fixes the crash:

-    <AndroidEnableMarshalMethods>true</AndroidEnableMarshalMethods>
+    <AndroidEnableMarshalMethods>false</AndroidEnableMarshalMethods>

Offer stands to give you guys access so you can understand/fix this and get AndroidEnableMarshalMethods working.

[jonpryor]

@mfeingol: your most recent comment confuses me, because LLVM Marshal Methods are disabled by default in .NET 9, and have been since .NET 9 RC2:

• https://github.com/dotnet/android/blob/release/9.0.1xx/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets#L326-L327
• d6240d4

Were you explicitly enabling them in your project?

That said we thought we had figured out the cause of hangs related to LLVM Marshal Methods (#9343), so this crash is new to me. The presence of GetByteArrayRegion() in the backtrace is also interesting, as that's not a method that we use in bindings. (We bind it; we just don't directly use it in generated bindings.) I wish we had more than 3 frames of backtrace. ☹️

Are you able to simplify your repro to share it publicly?

[mfeingol]

@jonpryor:

Yes, I had explicitly enabled AndroidEnableMarshalMethods in my project. The crash happens with one particular sequence of events (displaying a relatively complex set of tracks on a map) and so some time had passed between me enabling the option and then observing the crash. That's why it took a while to put 2+2 together.

Unfortunately it would be a lot of work to provide a public repro. As I said, I'm happy to give you access to my project. The repro steps above will reproduce the crash 100%.

[jonpryor]

@mfeingol: unfortunately we won't be able to look into your project anytime soon. ☹️ If you don't mind that, we'd love to be able to view it some time next year.

[mfeingol]

That's fine. This was a .NET 9 adoption blocker for me, but now that I understand the cause I can work around it.

Question: if I were able to produce a quick and dirty repro, would that help accelerate things?

[jonpryor]

@mfeingol asked:

if I were able to produce a quick and dirty repro, would that help accelerate things?

Maybe; it depends on how easily we can get more of the native stack trace, and where that points us to. If we don't get more stack trace, I'll need to wait for people to return from vacation so we can get more of a stack trace. If we do have more of a stack trace, it'll depend on where it points us to.

(As is, winter vacations have begun…)

[jfversluis]

Offer stands to give you guys access so you can understand/fix this and get AndroidEnableMarshalMethods working.

Just as an FYI here, we're not able to just look at private repos/proprietary code. All reproductions should be publicly hosted and not an attached zip file.

Question: if I were able to produce a quick and dirty repro, would that help accelerate things?

So probably yes, but in this case that is not the only reason for delay, its December and a good number of people will be out of office at this time.

@jonpryor is this still MAUI specific? Else you can move it to Android?