In our Crashlytics data, we see lots of reports from older devices, as below. Our application appears to be crashing when the system goes to clean up memory.
The application does include native code that malloc()s to the heap. Auditing every line by hand is not feasible. We do not have access to all of the source code, and the code base is large.
Currently, we have no known way to reproduce this "in the laboratory." We only have these mysterious traces.
...
# OS Version: 5.0
# Device: Galaxy Note3
# RAM Free: 4.2%
# Disk Free: 34.8%
#0. Crashed: .our.app.id|
0 libart.so 0xb4d24180 (Missing)
1 libart.so 0xb4d244b7 art::gc::collector::MarkSweep::ProcessMarkStack(bool)
2 libart.so 0xb4d2454d art::gc::collector::MarkSweep::MarkReachableObjects()
3 libart.so 0xb4d25491 art::gc::collector::MarkSweep::MarkingPhase()
4 libart.so 0xb4d255bf art::gc::collector::MarkSweep::RunPhases()
5 libart.so 0xb4d1ca87 art::gc::collector::GarbageCollector::Run(art::gc::GcCause, bool)
6 libart.so 0xb4d3c43b art::gc::Heap::CollectGarbageInternal(art::gc::collector::GcType, art::gc::GcCause, bool)
7 libart.so 0xb4d3d881 art::gc::Heap::ConcurrentGC(art::Thread*)
8 boot.oat 0x745b23db (Missing)
I am looking for tips on how to approach/debug this crash. What causes this trace? What steps can I take to reproduce it, locally? What is making the garbage collector unhappy?
