I am working on a app, where I will use android NDK & JNI.
Whenever I run my app on any android 4.0 or higher version... my app will crash and gives the following error...
A/libc(18556): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
D/libEGL(18606): loaded /system/lib/egl/libGLES_android.so
D/libEGL(18606): loaded /system/lib/egl/libEGL_adreno200.so
D/libEGL(18606): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
D/libEGL(18606): loaded /system/lib/egl/libGLESv2_adreno200.so
I/Adreno200-EGLSUB(18606): <ConfigWindowMatch:2078>: Format RGBA_8888.
D/OpenGLRenderer(18606): Enabling debug mode 0
Main problem is Fatal signal 11 (SIGSEGV) at 0xdeadbaad(code=1)
If anyone know about this... then tell me the reason.
initially, the segmentation fault and, specially the 0xdeadbaad, would mean a memory corruption or similar but, I recently found that, with the NDK, this is also the default behaviour for assertions: on assert fail it sends SIGSEGV, instead of SIGTRAP, and sets the memory pointer to this hex string.
You should check that your code is calling to assert or, in case you're using third party's software, check that you're passing the proper values to every call. A quick way to check this would be building your library with NDEBUG set to 1 (by default if you set APP_OPTIM := release in your Application.mk) and check if you still have exactly the same problem.
Hope this helps.
Related
I've developed MAUI application. Eveything works perfectly on emulator and I want to try it out on my Xiaomi Redmi note 9. But it fails with:
Loaded assembly: /data/data/com.companyname.mauieventsamplecs/files/.__override__/System.Numerics.Vectors.dll [External]
[monodroid-assembly] open_from_bundles: failed to load assembly lt-LT/System.Private.CoreLib.resources.dll
[chatty] uid=10359(com.companyname.mauieventsamplecs) identical 2 lines
[monodroid-assembly] open_from_bundles: failed to load assembly lt-LT/System.Private.CoreLib.resources.dll
[uieventsamplec] Process terminated due to "Infinite recursion during resource lookup within System.Private.CoreLib. This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names. Resource name: IO_FileName_Name"
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 1418 (uieventsamplecs), pid 1418 (uieventsamplecs)
I pinpointed that it's the problem of different CPU. By default, the app is building on Any CPU (emulator runs x86_64 system). Which I would hope should include arm64-v8a, but it seems to only include all Intel CPU. Tried launching arm64-v8a emulator, but it's not supported since my device is Intel and not AMD
I tried changeing solution platform to ARM64, but ether that did not help or, you need to something more than just adding new solution platform and assigning it to actually make it work.
So my question is: how one should set up the MAUI to launch on local arm64-v8a if that's even possible.
Turns out it was the problem based on lt-LT/System.Private.CoreLib.resources.dll After few days of debugging and finally switching my phone language from LT to US in my phone settings it fixed the problem.
Try set in MauiApp1.csproj
<PropertyGroup Condition="$(TargetFramework.Contains('-android')) and '$(Configuration)' == 'Release'">
<!--<RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>-->
<RuntimeIdentifiers>android-arm;android-arm64</RuntimeIdentifiers>
</PropertyGroup>
The code for my Dart/Flutter application communicates with my native dynamic .so library, which is very performance intensive. The library is written in Rust. It works fine with targets aarch64-linux-android and x86_64-linux-android. When I run with target armv7-linux-androideabi the following line (Dart Code) crashes.
final dylib = DynamicLibrary.open("libmyimportantlib.so");
Here is the error message: Note that no code in the library is run, the crash occurs as soon as it is loaded (or tries to load).
F/libc ( 7651): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 7742 (DartWorker)
Can anyone tell me why it works on all other targets but not armv7-linux-androideabi?
I fixed the problem by downgrading the NDK version from 21 to 19. Apparently there is a problem with libc in the armv7-linux-androideabi target for version 20 and up.
I just run into s problem.When I changed my gradle version to 2.1.0(old version is 1.5.0),my code went wrong.And it's wierd there is no logcat,so I just don't know how to find the problem and the wrong part code. I have tryed to add android:allowClearUserData="true" in my AndroidManifest .it turns out not working. when I change my gradle version to the old one,it goes well.I am a new coder,and I use Retrofit to do the network job.plz just help me.Oh and I open the OpenGL stack in the logcat,It will call glGetError() then it goes crush.
From your description, I have no idea. If only upgrading AS, it should be not crashed, but for possible updated SDK or Build tool Env. If you back to 1.5, even no crash when using same platform sdk, support library sdk?
After upgrading 2.1.0, When was crash happened? launching app, or opening some Activity? If later, you should limit your code to some extension, then searching from Google.
From crash info, it should be related with JNI. if you use JNI,your app has a library path in the app installed directory to list all support ABI .so. You could found the differ btw woking machine and abnormal one. From this stackOverflow, you can try too.
Being new to Android NDK Caffe, I would like to use built version in my Android project. I tried to run this built sample demo, but while running, it showed the following:
03-26 14:46:35.697 2800-3042/com.sh1r0.caffe_android_demo A/libc﹕ Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 3042 (AsyncTask #1)
(the app crashed)
I can see that the sigsev signal is thrown through android AsyncTask.
The problem could come from this function.
caffeMobile.predictImage(strings[0])[0]; //line 160 of MainActivity
This signal comes from JNI and it is very difficult to know where is the problem unless you can debug natively (through ndk) the app. The caffe-sample is not configured to debug on native method.
Try this issues to manage the error:
Ensure that your image path in this string[0] arrays are not empty. and exists.
Ensure that the other caffeMobile functions are able to exec without
problems, for example:
caffeMobile = new CaffeMobile();
caffeMobile.setNumThreads(4);
caffeMobile.loadModel("/sdcard/caffe_mobile/bvlc_reference_caffenet/deploy.prototxt", "/sdcard/caffe_mobile/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel");
If you are able to execute the other functions, probably your image path is not correct, check.
If you are not able to execute loadModel or setNumThreads function, probably the apk is not loading libjni.so library correctly , or the jni bridge is not able to locate jni functions.
I am tracking a bug in my project. From time to time, my app gets killed and in the logcat there is always the following line:
D/Zygote ( xx): Process xxxx terminated by signal (11)
I have been searching about this error and I always find mentions to NDK.
I am developing a project that uses a third-party C library. I do not know the library in great detail, but I can tell you that it does some network communication with a server. In my project there are several Services, some of which use this library.
So my question is, does this error always imply that the problem comes from the C library?
If not, could you give me examples of Java code in Android, that could cause this error as well?
Thanks.
EDIT: By the way, in the logcat output there is no stack trace before the previous line.
Most likely, SIGSEGV was reported before in your log. It may be quite a while earlier than the final message. This is an actual snapshot of one of such crashes in my logs:
01-29 16:00:39.124 F/libc ( 3033): Fatal signal 11 (SIGSEGV) at 0x0000002c (code=1)
... many more ...
01-29 16:00:48.367 D/Zygote ( 116): Process 3033 terminated by signal (11)
You can see that it took almost 10 sec for Zygote to report process termination after the fatal signal was received. Your milage may vary.
The actual reasons for SIGSEGV may be within the third-party C library, or in your Java, or in the way you call the C library. Note, for example, that it's forbidden to make most of JNI calls while a Java Exception is raised.