Seeing native crash (“memory violation”, sig=11) instead of Android stack trace

Question

I recently started seeing a lot more native crashes in my app, in situations where it seemed like I should be seeing a managed crash and an Android stack trace. With a native crash, the app closes immediately, without the "Unfortunately your_app_name has stopped" box. And instead of a nice Android stack trace in logcat, I see something like this:

04-01 16:07:53.165 1263-1263/? E/audit: type=1701 msg=audit(1459544873.165:4214): auid=4294967295 uid=10535 gid=10535 ses=4294967295 subj=u:r:untrusted_app:s0 pid=2372 comm="app.debug" reason="memory violation" sig=11

To test this, I intentionally generated a NullPointerException with the following code, within the onClick() method of an OnClickListener:

Log.v("debugtag", "" + ((String)null).length());

I knew for sure that this should result in an Android stack trace, but instead I saw only the output associated with a native crash. Something is clearly interfering with exception handling.

I noticed that this started happening following an upgrade to Flurry 6.3.0. Has anyone else seen this happening?

Answer 1

I downgraded to Flurry 6.2.0, and this problem went away. Instead of native crashes, I now see full Android stack traces, as expected.

When debugging an app with Flurry 6.3.0, I noticed that I would sometimes end up in Flurry's uncaughtException() method just prior to the native crash. The decompiled Flurry code is clearly obfuscated. Within class "ma" there is a private inner class "a" which implements UncaughtExceptionHandler. In the uncaughtException() method of inner class "a", this is what I see as the first four lines of code:

ma var3 = ma.this;
Throwable var8 = var2;
Thread var7 = var1;
Set var9 = var3.c();

In executing the last line of code, the debug session ends and the native crash occurs.

I have reported this situation to Flurry. I don't yet know whether this is something that is peculiar to my app, or whether this is an issue with Flurry. I'll update here as additional information becomes available.

I did try calling FlurryAgent.setCaptureUncaughtExceptions(false) prior to calling FlurryAgent.init(), but the native crash still occurs.

UPDATE: Flurry reports the issue fixed in their 6.3.1 release. According to their release notes , the issue introduced in 6.3.0 only affected debug builds -- not release builds.

Answer 2

Same here. Have to downgrade to 6.2.0 to solve this issue.