Android SDL2 Startup Crash - android

Can somebody please help me? I have a test SDL2 application which runs on my phone just fine. I took a copy of the sample app and began porting in code from my own application which builds and links just fine.
My application crashes on startup with the below error in the log (last line):
05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Trying to load lib /data/app-lib/org.libsdl.app-13/libSDL2.so 0x42b0fb20
05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Added shared lib /data/app-lib/org.libsdl.app-13/libSDL2.so 0x42b0fb20
05-22 16:24:48.271 14834-14834/org.libsdl.app D/dalvikvm: Trying to load lib /data/app-lib/org.libsdl.app-13/libmain.so 0x42b0fb20
05-22 16:24:48.281 14834-14834/org.libsdl.app A/libc: Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 14834 (org.libsdl.app)
I have commented out my main() code and replaced this content with the main() from the sample app and it still crashes.
I'm faced with the long-winded task of incrementally including source files and components until I can identify the cause.
Does anybody know of a common cause for this please?
I am doing a clean build and run each time.

It looks like you have logcat's output filtering on. There should be a stack trace in the output after the 'fatal signal' line, which is visible if you select 'No filters' in logcat. Decoding that stack trace will hopefully make your search a bit narrower.

Related

Xamarin.Forms Android app is failing build with System.Security.Cryptography.Cng error

I have suddenly hit a wall with testing my Xamarin.Forms app. IT has suddenly started throwing the two messages below and failing (on my Android Emulator) immediately after the splash screen disappears.
I get the following warning during the build:
Ignoring C:\Users\geral\.nuget\packages\system.security.cryptography.cng\4.3.0\ref\netstandard1.6\System.Security.Cryptography.Cng.dll as it is a Reference Assembly
And then the Output windows shows these message when the app fails:
11-18 09:33:29.257 D/Mono (31723): Assembly Ref addref Xamarin.GooglePlayServices.Tasks[0xe1503180] -> Mono.Android[0xe15031e0]: 26
11-18 09:33:29.260 D/Mono (31723): Assembly Loader probing location: 'System.Security.Cryptography.Cng'.
11-18 09:33:29.260 F/monodroid-assembly(31723): Could not load assembly 'System.Security.Cryptography.Cng' during startup registration.
11-18 09:33:29.260 F/monodroid-assembly(31723): This might be due to an invalid debug installation.
11-18 09:33:29.260 F/monodroid-assembly(31723): A common cause is to 'adb install' the app directly instead of doing from the IDE.
In searching the web, I found a few articles that seemed related but nothing fixes the error. I have updated all NuGet packages and the Android SDK to the latest available. I am out of ideas.
https://forums.xamarin.com/discussion/63584/android-could-not-load-assembly-xxx-during-startup-registration
https://forums.xamarin.com/discussion/42405/debug-deployment-to-device-works-fine-release-fails-with-odd-messages-anybody-have-a-fix-for-this
Anyone have additional suggestions?
The actual answer was a little obvious after I had some time to come back to it. I added the NuGet package directly to my projects and now things are working correctly again. I had assumed the Reference would be sufficient, but in this case a direct reference was apparently needed. Still not sure why, or what changed that made it suddenly become a problem.
But if you get these message in the future try adding the package directly.

Android caffe built demo shows error

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.

my native android project shows an error "05-13 14:00:09.930: A//system/bin/app_process(5774): stack corruption detected: aborted"

In my latest project , I use two native libraries.Some time it shows an error code in log cat
"05-13 14:00:09.930: A//system/bin/app_process(5774): stack corruption detected: aborted",
But sometimes it work properly.I dont know how to solve this problem any one please help me.

Is "Process terminated by signal (11)" always related to NDK?

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.

Application crash with android 4.0 or higher version

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.

Categories

Resources