Develop Reference

Debugging an Android crash without a stack trace

This app instantiates a WebView on app launch without adding it to the UI tree. This is done for preloading purposes.
When finally adding the WebView to the UI tree later on, the app crashes without a stack trace.
At the time the WebView gets added to the UI tree, logcat shows the following on an emulator running API level 22:
D <last app event before adding preloaded webview to ui tree>
W ResourceType: No known package when getting name for resource number 0xffffffff
E eglCodecCommon: glUtilsParamSize: unknow param 0x000085b5
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b49
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b4b
E eglCodecCommon: glUtilsParamSize: unknow param 0x00008b4a
D AndroidRuntime: >>>>>> START com.android.internal.os.RuntimeInit uid 10059 <<<<<<
D AndroidRuntime: CheckJNI is ON
E cutils-trace: Error opening trace file: Permission denied (13)
E memtrack: Couldn't load memtrack module (No such file or directory)
E android.os.Debug: failed to load memtrack module: -2
D AndroidRuntime: Calling main entry org.chromium.components.crash.browser.CrashpadMain
W linker : libwebviewchromium.so: unused DT entry: type 0x6ffffef5 arg 0x4c34
W linker : libwebviewchromium.so: unused DT entry: type 0x6ffffffe arg 0x4bd4
W linker : libwebviewchromium.so: unused DT entry: type 0x6fffffff arg 0x3
E chromium: [0722/152535.383241:ERROR:elf_dynamic_array_reader.h(61)] tag not found
E chromium: [0722/152535.394807:ERROR:file_io_posix.cc(140)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
E chromium: [0722/152535.394897:ERROR:file_io_posix.cc(140)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
E chromium: [0722/152535.401624:ERROR:system_snapshot_linux.cc(125)] Couldn't read property ro.product.board
D AndroidRuntime: Shutting down VM
I WindowState: WIN DEATH: Window{2507ca0c u0 com.myapp.debug}
Does this point to the root cause of the crash?
I'm wondering if they are instead part of a crash recovery/dump mechanism (due to the reference to "CrashpadMain" before the errors), and if I would be able to find a stack trace elsewhere. While I can use adb bugreport, I don't know where to look in the report for information on the crash instance.
Of note, I've only been able to reproduce this crash (though consistently) on emulators, and only running API levels 22, 25, 27 and 29. A physical device, and an emulator running API level 23, do not reproduce it.

From the crash output it looks like the builds you're using have is_official_build=true set? (which makes sense for perf I guess)
This basically prevents Android from generating useful crash dump output at all, because the unwind tables are omitted from the binary. The only way to debug crashes in this kind of binary is to use Crashpad dumps, but those are unlikely to be hooked up usefully in a test environment?
Build with exclude_unwind_tables=false to override the default. This will increase binary size quite a bit, but should result in you getting a meaningful stack backtrace with more than one frame. You should then be able to symbolise the stack trace addresses to find out what's crashing.
exclude_unwind_tables
Current value (from the default) = true
From //build/config/compiler/compiler.gni:103
Exclude unwind tables by default for official builds as unwinding can be
done from stack dumps produced by Crashpad at a later time "offline" in the
crash server. Since this increases binary size, we don't recommend including
them in shipping builds.
For unofficial (e.g. development) builds and non-Chrome branded (e.g. Cronet
which doesn't use Crashpad, crbug.com/479283) builds it's useful to be able
to unwind at runtime.

React-native-webview: net::ERR_FAILED

Bug description:
The first time I open my app the website loads correctly in the WebView. Then I go to the homescreen and after a while I return to the app and gets the following error:
Website not available
The website at https://www.example.com?param=value could not be loaded because:
net::ERR_FAILED
Has anyone seen this error before?
Here is some logs from Android Studio that may or my not be related/useful.
2019-06-24 10:59:11.233 16101-16166/? W/cr_ChildProcLH: Create a new ChildConnectionAllocator with package name = com.android.chrome, sandboxed = true
2019-06-24 10:59:11.237 16101-16101/? I/cr_BrowserStartup: Initializing chromium process, singleProcess=false
2019-06-24 10:59:11.239 16101-16101/? W/ResourceType: Failure getting entry for 0x7f130537 (t=18 e=1335) (error -2147483647)
2019-06-24 10:59:11.241 16169-16169/? E//system/bin/webview_zygote32: failed to make and chown /acct/uid_99051: Permission denied
2019-06-24 10:59:11.241 16169-16169/? E/Zygote: createProcessGroup(99051, 0) failed: Permission denied
2019-06-24 10:59:11.244 16169-16169/? W//system/bin/webview_zygote32: Using default instruction set features for ARM CPU variant (cortex-a9) using conservative defaults
2019-06-24 10:59:11.248 1700-6616/? I/ActivityManager: Start proc 16169:com.android.chrome:sandboxed_process0/u0i51 for webview_service dk.MYAPPNAME.app/org.chromium.content.app.SandboxedProcessService0
2019-06-24 10:59:11.264 1991-1991/? I/chatty: uid=10016(u0_a16) com.android.systemui identical 1 line
2019-06-24 10:59:11.265 16169-16169/? I/SamplingProfilerIntegration: Profiling disabled.
2019-06-24 10:59:11.289 16197-16197/? E/asset: setgid: Operation not permitted
To Reproduce:
I have only been able to reproduce this error in release - not in debug. This error happens after loading the app the first time, then leaving it and return to the app after a few hours.
Maybe it is related to cache.
The problem persist when I force quit the app. If I reinstall the app it is working for a while.
Expected behavior:
Website should fully load.
Screenshots/Videos:
Environment:
- OS: Android (Huawei P20 Pro and multiple other Android phones)
- OS version: Android 8
- react-native version: 59.3
- react-native-webview version: 5.6.2

I found a fix for this issue!
It looks like a broken service worker stalled the website.
I solved it by using the injectedJavascript prop in my WebView to inject the following lines of code:
navigator.serviceWorker.getRegistrations().then(function(registrations) {
for (let registration of registrations) {
registration.unregister();
}
});
It is a bug in Google Chrome 75.

Loop I/PhoneWindow: generateLayout isLightNavi false, Visibility: 0 I/DecorView: It non-support bigbang

I'm new to Android. I'm having a weird loop on debug in Android Studio, and my app doesn't open. I'm using API 28 (Android Pie)
Any idea about what is the problem?
I/DecorView: It non-support bigbang
I/PhoneWindow: generateLayout isLightNavi false, Visibility: 0
I/DecorView: It non-support bigbang
I/PhoneWindow: generateLayout isLightNavi false, Visibility: 0
I/DecorView: It non-support bigbang
I/PhoneWindow: generateLayout isLightNavi false, Visibility: 0
...

These log statements are a red herring. Are you using a Nokia by chance? I noticed the bigbang log statement on my device as well. My guess is that Nokia added this log statement as part of some modifications they made to the system image. This is unfortunately common in Android development. I often notice strange log statements in my app's logcat, which may look like errors, but aren't related to my app's code at all.
If your logcat doesn't show an additional error besides what you shared, try turning off the "Show only selected application" filter. Sometimes when an app fails to start, the system will log an error instead of your app's process.

Malloc debug on Android Nougat doesnt work for my Native code

I am trying to find memory leaks and corruptions in my native code, which is part of a sample java app. Since the procedure for using malloc debug has been updated from Nougat onwards (ref: Malloc Debug for Android N), I have followed the steps in that page to set the options of my interest.
Fortunately, I was able to get the mem corruption detection work (by use of guard option) for a simple buffer overflow in my native code. But, whatever option I use, I couldn't get the leaks detected.
I tried these options:
adb shell setprop libc.debug.malloc.options backtrace
adb shell setprop libc.debug.malloc.options leak_track
I also tried a combination of both options. I didnt see any mallocs or leaks present in my code being captured in logcat. In fact, for most devices I see that device is stuck in bootup when 'backtrace' option is set.
However, what I see is in the logs, is apparently false-positives for leaks in lot of other system programs:
12-16 13:05:51.908 8396 8396 E malloc_debug: +++ chmod leaked block of size 152 at 0x7f7de4b0e0 (leak 1 of 19)
...
12-16 13:05:52.156 8423 8423 E malloc_debug: +++ chown leaked block of size 152 at 0x7f8384b0e0 (leak 1 of 26)
...
12-16 13:05:56.533 8845 8845 E malloc_debug: +++ getprop leaked block of size 152 at 0x7fb684b0e0 (leak 1 of 17)
...
12-16 13:07:24.036 12393 12393 E malloc_debug: +++ /system/bin/dex2oat leaked block of size 131072 at 0xeb22c010 (leak 1 of 2452)
...
12-16 13:07:49.192 13734 13734 E malloc_debug: +++ logcat leaked block of size 5176 at 0x7f8dc5f020 (leak 1 of 21)
So, I have two questions in this context:
Does my apk need to be in a specific location for backtrace/leak_track to work? Was it ever tested for apks before, at least on N?
Do I need to set any other option for leak detection to work?
It looks like Malloc debug on Nougat is not explored much, so I didnt see any results on Google for any known issues or restrictions.
More details on my setup:
- Android Nougat 7.0
- 64 bit chipset
- Java sample app, with native code as shared lib

SIG33 when debugging native Android

I'm using Android Studio to debug a NativeActivity app written in C++
In my C++ code the first thing I do in android_main() is wait 10 seconds for the debugger to attach. In the 'Debug' window I see:
Now Launching Native Debug Session
and then after a few seconds
Debugger attached to process 28458
and then right after it attaches, the debugger is stopped with a signal:
Signal: 33 (signal SIG33)
I press 'Resume Program' and then I get the same signal again and again for 7-8 times. After that, the program continues as expected, debugger attached and I am able to stop it at breakpoints.
What's the meaning of that SIG33? how can I prevent it?

Signal 33 is used internally by bionic for the backtrace facilities.
See comment in __libc_current_sigrtmin.cpp.
// POSIX timers use __SIGRTMIN + 0.
// libbacktrace uses __SIGRTMIN + 1.
// libcore uses __SIGRTMIN + 2.
See definition of __SIGRTMIN for generic, arm, x86, and mips.
#define __SIGRTMIN 32
I think that SIG33 is caused by gdb and gdb is not correctly ignoring it.

Those can be ignored and/or silenced using below GDB command-line:
handle SIG33 nostop noprint

SIG33 is used to signal about "threading libraries" by LLDB.
Excerpt from LLDB source:
AddSignal (33, "SIG33", false, false, false, "threading library internal signal 2");
But I don't seem to understand the reason why your code is getting this. May be due to some minor dependency issues.