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.
Related
I have been stuck with Fatal Signal errors since using Visual Studio 2019 or 2022 to compile my Xamarin Android Project for more than 3 weeks.
I have used ndk-stack and other tools to see any meaningful stack trace I have failed and our project is not going ahead because of this.
Please note that the same exact code base works perfectly stable if I produce an APK using visual Studio 2017.
Visual Studio 2019 uses Xamarin.Andriod.SDK 12.0.0.3
Visual Studio 2017 uses Xamarin.Android.SDK 9.7.1.0
I have attempted to upgrade to Android 12 but our project is Huge and require significant amount of work. It does not seem to be an option at this point.
The reason I want to use 2019 or 2022 is because of google play store and producing app bundle instead of APK. Visual Studio 2017 does not have app bundle option.
My projects target Android 9 and I am also using PortSip Libraries. I have done extensive googling. I have not found any solid evidence if there is a problem with Xamarin Android SKD in 2019 or a problem with my Samsung Device Tab S6. The only answer I found here is:
Why application is dying randomly?
If this the case why an APK produced by 2017 does not have any segmentation faults or any race conditions.
I have handlers in c# to catch any error but non of them catches these. My app uses google MAPs and we are drawing many layers and updates on the MAP.
My app also receives many signalr updates and makes calls to WCF services.
Examples of errors:
03-09 19:54:53.811 9984 12254 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x40000000080 in tid 12254 (Thread Pool Wor), pid 9984 (------)
03-09 19:54:53.836 12404 12404 E chromium: [0309/195453.835730:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)
03-11 00:35:05.469 27236 27236 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7c13725238
We had a very similar problem with PortSip (null reference exception that was caused by the Garbage Collection thread in PortSip). We found that the problem was in the way a key class PortSip constructor contained mutual references with other classes. When those classes were disposed a null reference exception occurred on the garbage collection thread.
You reported that "I have handlers in C# to catch any error but none of them catches these". We found that to be the case as well. It turned out that since the crash was happening on the CG thread inside the PortSip library - adding error handling in C# had no effect.
If your crashes are also experiencing these symptoms - I will dig into the code and document our fix.
I have linked some c++ codes to android studio project and it works with no problem, but every time I encounter with a runtime error in java code, android studio won't tell me the problem precisely and reports only this error in debugger:
Signal = SIGSEGV (signal SIGSEGV: invalid address (fault address: 0xc))
What is the problem?
This primarily occurs due to one of the 2 reasons :
1) Invalid memory reference.
2) Eating up too much memory.
Now, debugging this issue can be a bit intimidating.
So start finding out points where your code may be doing INVALID MEMORY ACCESS causing SIGSEGV error or points where your code is starting too many threads.
And You have to find out if this issue is regularly occuring or 1 in 5(or so) times.
Because I encountered the problem in one project and that occured 1 in 5-6 times.
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.
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 doing an application with native code.
I have a bug, that sometimes produces this error in the logcat, but not produces runtime error:
06-27 18:14:47.526: A/libc(32659): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 592 (Thread-1045)
I have read at internet and it says that could be produces for native code, in concret for the bad acess to memory.
Someone knows somethig?
Thanks
This is a seg fault. Its occurring at address 0, which means you're dereferencing a NULL pointer. Its occuring in libc, so its certainly happening in native code, which may be through you calling it directly or through the framework calling it. That's all you can tell from that one line.
I had the same error with the same address. After "googeling" for days i was stucked.
Today i found the solution (in my case): i use win 8 x64 with eclipse Juno. The problem was solved when i have disabled the UAC from windows.
Both the adb.exe and eclipse (in my case) were runned in admin mode.
Hope will help someone.