I've been getting some crashes in my app out in the field an one crash that I received is very interesting in nature. For one of the crashes happening the service I am using is reporting a SIGSEGV SEGV_MAPERR in libwebviewchromium.so and the only information coming back is the address 0x00000000fbadbeef. It seems kind of ironic that not only the address is readable, but it also so consistent.
I'm unable to create the crash locally so I don't have a full trace, but I was curious if there is a know issue or reason for the 0xfbadbeef address in libwebviewchromium and if ther is a fix for it or way to reduce it from happening.
From the Chromium WebKit sources — see the comment just above the macro definition — , this is their code for "known, unrecoverable errors like out-of-memory".
Related
We use Crashlytics for reporting crashes faced by our Android app users. A lot of our code is native (c++), hence a lot of crashes are in native code. However most (if not all) of them end up getting grouped under "abort_message.cpp line 77". And this is the top part of the stacktrace for all kind of different crashes -
I have tested by making different kinds of crashes in different files, like throw std::runtime_error("Testing crash"), throw std::logic_error("Testing crash2"), but all of them end up having the top few frames same (as the image above).
Now since the top frame of crash stack is abort_message.cpp line 77 for all of them, they get grouped under same head.
Grouping dissimilar crashes in same group, makes it hard to prioritize and target crash fixes. So is there anyway we can fix this? Or workaround this?
NOTE: We are uploading native symbols to crashlytics alright, and our stack traces are quite detailed.
Another thing that bothers me is that different type of crashes are all reported as SIGABRT.
Fabric/Firebaser here -
This looks to be a C++ exception that Crashlytics is not unwinding very well - this is an aspect of NDK integration with Crashlytics that we're looking to improve for the future. When a C++ exception is thrown, the signal that is raised by an uncaught C++ exception is processed rather than handling the exception itself, resulting in these first few frames of the stacktrace being the same and grouping together different issues as a result.
It should still have the relevant crash information, so the frames below should be different, but the blame frame will be that abort_message frame.
Thanks for the report - it's definitely something we're looking into making better soon.
I also have the same complaint.
Is there a workaround?
Just received a spike alert from Firebase from having the same error spiking, and they were all unrelated crashes (from throw exceptions incorrectly grouped as the same)
I'm making a research about if there is any problem in compiling native code for Android 5 or superior using NDK 9 but couldn't yet find any answer.
I already made a long search in source.android.com, this page was the closer I could get to answering but it is not clear yet...
I'm asking this because I'm having a SIGSEGV problem in a native code written in C to be put in my Android app. Before Android 5, the code run smoothly but in every device using android 5 or superior gives this error ocasionally (sometimes the code runs without error).
For the NDK version, it should be fine. It's an older vintage but should still
build your code correctly. I'd try and update as soon as you can though, just to
keep current. I don't think this would be the cause of the crash.
Android 5 introduced the Android Runtime (ART) by default. Prior to this
the VM used was Dalvik. I found that the JNI layer in Android 5 was a
lot stricter. In the old Dalvik world you could often get away with, for
example, sharing a JNIEnv pointer between JNI calls. In ART this is not
possible and will always crash. Just to be clear, in Dalvik it should not work
either but you could get away with it, so the mistake went undetected.
Another thing to watch out for is creating large local variables, such as
arrays, on the stack. In Dalvik each thread had 2 stacks, one for JNI code and
one for Java, but in ART the stack is shared between native and Java. So the
JNI code may be running out of stack and crashing. These kinds of crashes can
be very difficult to track down. Code inspection looking for local
(non-malloc'd) arrays has been the way I've found some in the past.
Is there a good stack trace from logcat? Usually you can debug a SIGSEGV by
building in debug and passing the stack trace through ndk-stack.
If you're lucky it gives you the line where your code crashes.
We are working on an Android app. We are using the Chilkat library to handle the email communication and it works well. Although, there may be a "issue" involving some JNI communication. From internet research and discussing with Chilkat, the problem may involve how EMOJI's are processed in messages.
Periodically, we get an error that hard crashes the app and it comes from the library call. It is a single line call that sometimes crashes depending on something within the message itself. Our call is...
tmpstr=email.getHtmlBody();
The hard crash error we get is:
JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xf0
Again, doing some internet searches on this message... this apparently is a more common issue than anyone wants but still needs to be addressed. Chilkat is working on a fix but in the meantime, we need to continue with the app.
What I am trying to figure out if there is a way that we can catch the error and prevent the app from crashing... maybe just flagging this message and continuing with the next message?
Seeing how I have never tried to catch an error from a 3rd party library, I am not sure where to go with this.
Any suggestions or examples that might help would be greatly appreciated.
Well, depending on error, you can always try to "fix" it. Working with legacy code is always hard and all you can do here are some hacks.
You can do few things here:
try to catch signals
make sure your app doesn't exit your JVM
Take a look here: http://jnicookbook.owsiak.org/recipe-No-015/ and here: http://jnicookbook.owsiak.org/recipe-No-016/
Maybe you will find some solution based on these samples.
I am developing an Android application using NDK. The application blows up with "SIGSEGV" error which I believe a segmentation fault error.
I looked at my code and I think memcopy and memmove might cause this error. I was wondering if there is a safe way to call these functions.
Also please let me know any well described NDK debugging tutorials or anything related. Thanks in advance.
The rule with those 2 is that you use memcpy when you're copying a block of bytes from one place to another, and the source and destination don't overlap. If they do overlap, you have to use memmove. However, using them incorrectly results in corrupted data, not segfaults. Segfaults happen when you try to read or write to a memory location that is invalid - its analogous to Java's NullPointerException. You want to triple check that you have destination, source and size in the correct order. Beyond that, we'll need to see some code.
You can use Android's "logcat" logging facility within NDK code, so if you need to understand where things are going bad, that can be pretty helpful (unless you're able to run gdb / gdbserver).
It's very possible that memcpy or memmov can cause a SIGSEGV. You need to be sure all your pointers are correct, and the buffer sizes are correct as well. If you make a mistake there, the best that can happen is your SIGSEGV and program crash. On the worse end, you could overwrite other memory in your application and not know until some time later (making it difficult to find the cause of the corruption).
I'm moving a project to the new Android Native Development Kit (i.e. JNI) and I'd like to catch SIGSEGV, should it occur (possibly also SIGILL, SIGABRT, SIGFPE) in order to present a nice crash reporting dialog, instead of (or before) what currently happens: the immediate unceremonious death of the process and possibly some attempt by the OS to restart it. (Edit: The JVM/Dalvik VM catches the signal and logs a stack trace and other useful information; I just want to offer the user the option to email that info to me really.)
The situation is: a large body of C code which I didn't write does most of the work in this application (all the game logic) and although it's well-tested on numerous other platforms, it's entirely possible that I, in my Android port, will feed it garbage and cause a crash in native code, so I want the crash dumps (both native and Java) that currently show up in the Android log (I guess it would be stderr in a non-Android situation). I'm free to modify both C and Java code arbitrarily, although the callbacks (both going in and coming out of JNI) number about 40 and obviously, bonus points for small diffs.
I've heard of the signal chaining library in J2SE, libjsig.so, and if I could safely install a signal handler like that on Android, that would solve the catching part of my question, but I see no such library for Android/Dalvik.
Edit: From Jelly Bean onwards you can't get the stack trace, because READ_LOGS went away. :-(
I actually got a signal handler working without doing anything too exotic, and have released code using it, which you can see on github (edit: linking to historical release; I removed the crash handler since then). Here's how:
Use sigaction() to catch the signals and store the old handlers. (android.c:570)
Time passes, a segfault happens.
In the signal handler, call up to JNI one last time and then call the old handler. (android.c:528)
In that JNI call, log any useful debugging info, and call startActivity() on an activity that is flagged as needing to be in its own process. (SGTPuzzles.java:962, AndroidManifest.xml:28)
When you come back from Java and call that old handler, the Android framework will connect to debuggerd to log a nice native trace for you, and then the process will die. (debugger.c, debuggerd.c)
Meanwhile, your crash-handling activity is starting up. Really you should pass it the PID so it can wait for step 5 to complete; I don't do this. Here you apologise to the user and ask if you can send a log. If so, gather the output of logcat -d -v threadtime and launch an ACTION_SEND with recipient, subject and body filled in. The user will have to press Send. (CrashHandler.java, SGTPuzzles.java:462, strings.xml:41
Watch out for logcat failing or taking more than a few seconds. I have encountered one device, the T-Mobile Pulse / Huawei U8220, where logcat immediately goes into the T (traced) state and hangs. (CrashHandler.java:70, strings.xml:51)
In a non-Android situation, some of this would be different. You'd need to gather your own native trace, see this other question, depending on what sort of libc you have. You'd need to handle dumping that trace, launching your separate crash-handler process, and sending the email in some appropriate ways for your platform, but I imagine the general approach should still work.
I'm a little bit late, but I had the exact same need, and I've developed a small library to address it, by catching common crashes (SEGV, SIBGUS, etc.) inside JNI code, and replace them by regular java.lang.Error exceptions. Bonus, if the client is running on Android >= 4.1.1, the stack trace embeds the resolved backtrace of the crash (a pseudo-trace containing the full native stack trace). You will not recover from vicious crashes (ie. if you corrupt the allocator, for example), but at least it should allows you to recover from most of them. (please report successes and failures, the code is brand new)
More info at https://github.com/xroche/coffeecatch
(code is BSD 2-Clauses license)
FWIW, Google Breakpad works fine on Android. I did the porting work, and we're shipping it as part of Firefox Mobile. It requires a little setup, since it doesn't give you stack traces on the client-side, but sends you the raw stack memory and does the stack walking server-side (so you don't have to ship debug symbols with your app).
In my limited experience (non-Android), SIGSEGV in JNI code will generally crash the JVM before control is returned to your Java code. I vaguely recall hearing about some non-Sun JVM which lets you catch SIGSEGV, but AFAICR you can't expect to be able to do so.
You can try to catch them in C (see sigaction(2)), although you can do very little after a SIGSEGV (or SIGFPE or SIGILL) handler as the ongoing behaviour of a process is officially undefined.