I have a patch that is crashing basically every Android xpcshell test, but for some reason there are no crash stacks: https://treeherder.mozilla.org/logviewer.html#?job_id=205595187&repo=try&lineNumber=1483 The log just looks like this: js/xpconnect/tests/unit/test_xpcomutils.js | xpcw: cd /sdcard/tests/xpc/js/xpconnect/tests/unit js/xpconnect/tests/unit/test_xpcomutils.js | xpcw: xpcshell -m -s --greomni /data/local/xpcb/target.apk -e const _HEAD_JS_PATH = "/sdcard/tests/xpc/head.js"; -e const _MOZINFO_JS_PATH = "/sdcard/tests/xpc/p/mozinfo.json"; -e const _TESTING_MODULES_DIR = "/sdcard/tests/xpc/m"; -f /sdcard/tests/xpc/head.js -e const _SERVER_ADDR = "localhost" -e const _HEAD_FILES = []; -e const _JSDEBUGGER_PORT = 0; -e const _TEST_FILE = ["test_xpcomutils.js"]; -e const _TEST_NAME = "js/xpconnect/tests/unit/test_xpcomutils.js" -e _execute_test(); quit(0); js/xpconnect/tests/unit/test_xpcomutils.js | [3561, Unnamed thread 46f0e080] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/workspace/build/src/xpcom/base/nsTraceRefcnt.cpp, line 209 js/xpconnect/tests/unit/test_xpcomutils.js | [3561, Main Thread] WARNING: No Android crash handler set: file /builds/worker/workspace/build/src/toolkit/crashreporter/nsExceptionHandler.cpp, line 1589 js/xpconnect/tests/unit/test_xpcomutils.js | [3561, Main Thread] WARNING: Error parsing GRE default preferences. Is this an old-style embedding app?: file /builds/worker/workspace/build/src/modules/libpref/Preferences.cpp, line 4896 js/xpconnect/tests/unit/test_xpcomutils.js | Segmentation fault The crash is likely early in XPCOM startup, so maybe that's why there is no information about the segfault.

Crashes in Android xpcshell tests normally produce minidumps and crash reports. For example, see https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=424132c4fc6f615d14c3bb05b155c940c0619cfe There is a current problem with Android xpcshell crash report symbolication -- bug 1499915. But in your case, it looks like there wasn't even a minidump produced. If the crash is early in XPCOM startup, that's probably the cause, and I don't know that we can do much about that.

Fair enough.