1

I've got a bit of Android NDK code that's called from Xamarin. Simple stuff that returns directly is OK, but when I create a background thread I get a SIGABRT (-6) and the app dies.

The background thread is created with std::thread(lambda). A background NDK thread is needed because this code has to unpack a very large data file and then run some CPU-intensive algorithms using the unpacked data.

Now SIGABRT appears to originate from libc, which supposedly is the symptom of an Application Not Responding. Yet this is supposed to affect only the main thread? In the developer options, I do have "show all ANR" options enabled, but that only blinks a few red frames around the stock Android software.

Why does Android confuse my background thread and the foreground thread? How do I tell Android not to kill my background thread?

Android v5.1.1 on stock Google/LG Nexus 5.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • The "abort" signal is generally expected to kill the entire process. Check your logcat output to see if there's an indication of the problem, such as an `assert()` firing, or heap corruption. – fadden Jun 15 '15 at 18:09
  • Well, the entire process does die, so that's not unexpected. Logcat is pretty clean except for the SIGABRT, and my own logging shows up at the expected places (foreground preparations OK, thread starts, process dies soon afterwards). – MSalters Jun 15 '15 at 20:22
  • Paste the crash in your question, from the top to the end of the backtrace. If there's a message in the logcat it'll likely be immediately above the crash dump. – fadden Jun 15 '15 at 21:09
  • @fadden: I'd wish I had a backtrace. Instead I get `F/libc ($PID): Fatal signal 6 (SIGABRT, code -6 in tid $TID (App.MyApp) I/libc ($PID): Suppressing debuggerd output because prctl(PR_GET_DUMPABLE)==0` – MSalters Jun 16 '15 at 06:36
  • Are you running setuid? Have you tried calling prctl(PR_SET_DUMPABLE) to reset the flag? Are you able to attach gdb to get a backtrace that way? None of this is related to ANRs, and any aborts from the Android framework or libraries should be preceded by a message, so it's likely something in a library you've imported is calling the libc `abort()` function. Might be worth trying http://developer.android.com/tools/debugging/debugging-log.html#viewingStd to see if there are diagnostics on stderr. – fadden Jun 16 '15 at 16:10
  • @fadden: The link you gave is for the Dalvik VM. I get a warning about unrecognized properties. I assume that's because 5.1.1 uses ART. ndk-gdb doesn't like the Xamarin project. – MSalters Jun 16 '15 at 18:03

1 Answers1

1

It turns out that SIGABRT is quite overloaded. It happens in reaction to applications not responding, calls to abort() and also unhandled exceptions. And the logcat output doesn't tell you which of these happened.

I found this out by dup'ing stderr - the unpacked data didn't match the algorithms in the app so the exception happened as soon as the slow algorithms were called.

Community
  • 1
  • 1
MSalters
  • 173,980
  • 10
  • 155
  • 350