Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3rd Party library internal invoke native code lead app crash #7532

Closed
jingliancui opened this issue Nov 5, 2022 · 7 comments · Fixed by #7560
Closed

3rd Party library internal invoke native code lead app crash #7532

jingliancui opened this issue Nov 5, 2022 · 7 comments · Fixed by #7560
Assignees
Labels
Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc.

Comments

@jingliancui
Copy link

Android application type

Android for .NET (net6.0-android, etc.)

Affected platform version

Version 17.3.6 Windows Version

Description

.Net6 app Invoke 3rd party lib will lead crash.
Native app didn't crash.

Please take a look at the attachment codes and run them.

Steps to Reproduce

JPushMAUI.zip
1.Unzip the ziped file.
2.Using Android Studio run the app that placed on the native folder with debug mode.
3.Using Visual Studio run the app that placed on the SampleApp folder with debug mode.
4.Native app normal run after occur JPushInterface.init(this); which wrote on MainActivity.java
5.SampleApp crash after occur CN.Jpush.Android.Api.JPushInterface.Init(this); which wrote on MainActivity.cs

Additions info:
Then we should focus on the logcat window on AS and the output window on VS for
[jiguang]
At last the crash are occur from the *.so exception because output window will show a message error like: fatal signal.

Take a look at csproj file because it need ManifestPlaceholder, But I've double checked in obj/Debug/net6.0-android/AndroidManifest.xml, I think all values are correctly set.

Did you find any workaround?

Sorry, I've no idea about that.

Relevant log output

[JIGUANG-JPush] [JPushInterface] action:init - sdkVersion:4.8.4, buildId:225
[JIGUANG-JPush] [AndroidUtil] action:checkValidManifest
[yname.sampleap] Accessing hidden method Landroid/app/ActivityThread;->currentActivityThread()Landroid/app/ActivityThread; (greylist, reflection, allowed)
[yname.sampleap] Accessing hidden field Landroid/app/ActivityThread;->mActivities:Landroid/util/ArrayMap; (greylist, reflection, allowed)
[JIGUANG-JPush] [JPushConstants] found messageReceiverClass :com.companyname.sampleapp.SampleReceiverat com.companyname.sampleapp by getCommonReceiverNames
[JIGUANG-JPush] [AndroidUtil] The fileprovider required for inapp-message is incorrectly configured, please check AndroidManifest.xml
[JIGUANG-JPush] [ActionHelper] doSingleAction: third_init
[libc] Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x40 in tid 32024 (jg_fr_pool_thre), pid 31955 (yname.sampleapp)
[monodroid-assembly] open_from_bundles: failed to load assembly Xamarin.AndroidX.ViewPager2.dll
Loaded assembly: /data/data/com.companyname.sampleapp/files/.__override__/Xamarin.AndroidX.ViewPager2.dll [External]
[TabLayout] MODE_SCROLLABLE + GRAVITY_FILL is not supported, GRAVITY_START will be used instead
[monodroid-assembly] open_from_bundles: failed to load assembly Xamarin.AndroidX.Lifecycle.Runtime.dll
Loaded assembly: /data/data/com.companyname.sampleapp/files/.__override__/Xamarin.AndroidX.Lifecycle.Runtime.dll [External]
@jingliancui jingliancui added Area: App Runtime Issues in `libmonodroid.so`. needs-triage Issues that need to be assigned. labels Nov 5, 2022
@grendello
Copy link
Contributor

@jingliancui could you please provide full logcat output of the crash on your device(s)? To produce the output, please run the following commands from the command prompt:

adb logcat -G 16M
adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
adb logcat -c
rem start the application on device here and wait for it to crash, then
adb logcat -d > log.txt

Please attach the resulting log.txt file, thanks!

@grendello grendello added need-info Issues that need more information from the author. and removed needs-triage Issues that need to be assigned. labels Nov 7, 2022
@ghost
Copy link

ghost commented Nov 7, 2022

Hi @jingliancui. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

@jingliancui
Copy link
Author

log.txt
Ok,@grendello , I've log them, please have a look. thanks.

@ghost ghost added need-attention A xamarin-android contributor needs to review and removed need-info Issues that need more information from the author. labels Nov 7, 2022
@grendello
Copy link
Contributor

@jingliancui thanks! I think it might be a runtime issue. The crash stack trace (just the relevant portion):

0x10a998
copy_stack_data_internal
/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:191
copy_stack_data
/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:246

0x10a7e0
mono_threads_enter_gc_unsafe_region_unbalanced_with_info
/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:476

0x9abe4
mono_runtime_invoke
/__w/1/s/src/mono/mono/metadata/object.c:2442

@lambdageek mind taking a look? Thanks!

@grendello grendello added Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc. and removed Area: App Runtime Issues in `libmonodroid.so`. need-attention A xamarin-android contributor needs to review labels Nov 7, 2022
@grendello grendello assigned lambdageek and unassigned grendello Nov 7, 2022
@lambdageek
Copy link
Member

lambdageek commented Nov 16, 2022

@grendello Looking at the stack trace and the code, it looks like mono_runtime_invoke is called from MonodroidRuntime::Java_mono_android_Runtime_register on a thread that's not attached to the runtime (MonoThreadInfo * is null in copy_stack_data).

Why does this code only attach to the runtime in !defined (NET6) - you still need to attach (using the root domain) even on net6:

https://github.com/xamarin/xamarin-android/blob/a96aa41a62094415ad042bad05e4811b06560ea4/src/monodroid/jni/monodroid-glue.cc#L2460-L2474

@grendello
Copy link
Contributor

@lambdageek good catch! Probably a mistake during separating classic and net6 code back in the day. I'll open a PR. Thanks :)

grendello added a commit to grendello/xamarin-android that referenced this issue Nov 16, 2022
Fixes: dotnet#7532

Whenever any MonoVM APIs are called, the current thread of execution
must be attached to the runtime or we risk native code crashes, for
instance:

    Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x40 in tid 1860 (jg_fr_pool_thre), pid 1792 (yname.sampleapp)
    backtrace:
      00 pc 0011588e  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so
      01 pc 001156ae  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so
      02 pc 00115575  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so (mono_threads_enter_gc_unsafe_region_internal+53)
      03 pc 000973c3  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so (mono_runtime_invoke+51) (BuildId: c54662bbf82dbdadd595ca9d3e31dce29735885f)
      04 pc 00027ace  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::Java_mono_android_Runtime_register(_JNIEnv*, _jstring*, _jclass*, _jstring*)+286)
      05 pc 000279a0  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_register+48)

The above trace translates to the following locations in the Mono
runtime:

    copy_stack_data_internal
    /__w/1/s/src/mono/mono/utils/mono-threads-coop.c:191
    copy_stack_data
    /__w/1/s/src/mono/mono/utils/mono-threads-coop.c:246

    mono_threads_enter_gc_unsafe_region_unbalanced_with_info
    /__w/1/s/src/mono/mono/utils/mono-threads-coop.c:476

    mono_runtime_invoke
    /__w/1/s/src/mono/mono/metadata/object.c:2442

In this case, a pointer to Mono thread information
structure (`MonoThreadInfo*`) is null in `copy_stack_data` which, in
turn, causes the segfault when the pointer is dereferenced.

In the case of issue dotnet#7532, `Java_mono_android_Runtime_register` is
called on behalf of a 3rd party library on a thread that is, most
likely, created by that library and thus not (yet) attached to the
runtime by the time the registration attempt is made.

Attach thread to the runtime by calling
`mono_jit_thread_attach (nullptr)` in DotNet builds to fix the issue.
`nullptr` is used because .NET only has a single AppDomain and there's
no need to pass around pointers to it.
jonpryor pushed a commit that referenced this issue Nov 30, 2022
…7560)

Fixes: #7532

Whenever any MonoVM APIs are called, the current thread of execution
must be attached to the runtime or we risk native code crashes, e.g.:

	Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x40 in tid 1860 (jg_fr_pool_thre), pid 1792 (yname.sampleapp)
	backtrace:
	  00 pc 0011588e  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so
	  01 pc 001156ae  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so
	  02 pc 00115575  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so (mono_threads_enter_gc_unsafe_region_internal+53)
	  03 pc 000973c3  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonosgen-2.0.so (mono_runtime_invoke+51) (BuildId: c54662bbf82dbdadd595ca9d3e31dce29735885f)
	  04 pc 00027ace  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::Java_mono_android_Runtime_register(_JNIEnv*, _jstring*, _jclass*, _jstring*)+286)
	  05 pc 000279a0  /data/app/~~lwgdvtQhIfK0II0Nd0mtag==/com.companyname.sampleapp-8yF54k9YuWCWpsuGRJvVQw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_register+48)

The above trace translates to the following locations in the Mono runtime:

	copy_stack_data_internal
	/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:191
	copy_stack_data
	/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:246

	mono_threads_enter_gc_unsafe_region_unbalanced_with_info
	/__w/1/s/src/mono/mono/utils/mono-threads-coop.c:476

	mono_runtime_invoke
	/__w/1/s/src/mono/mono/metadata/object.c:2442

In this case, a pointer to Mono thread information structure
(`MonoThreadInfo*`) is null in `copy_stack_data()` which, in turn,
causes the segfault when the pointer is dereferenced.

In the case of issue #7532, `Java_mono_android_Runtime_register()` is
called on behalf of a 3rd party library on a thread that is, most
likely, created by that library and thus not (yet) attached to the
runtime by the time the registration attempt is made.

Attach thread to the runtime by calling
`mono_jit_thread_attach(nullptr)` in .NET builds to fix the issue.
`nullptr` is used because .NET only has a single AppDomain and
there's no need to pass around pointers to it.

TODO: Try to create a test case.  Our attempted unit tests don't
cause an app crash when the fix isn't applied -- i.e. when
`mono_jit_thread_attach(nullptr)` *isn't* called -- which suggests
that we don't fully understand the reported bug report.
@jingliancui
Copy link
Author

@grendello This was fixed in .net7, Does it no plan fix for .net6?

@ghost ghost locked as resolved and limited conversation to collaborators Jan 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants