Unfortunately, in some cases our modules crash because of what I believe to be inconsistent memory management on our side. More precisely, the trace module for example crashes on x86 if its artist pass is created using a placement new operator with the current arena allocator. The following quick-fix solves the problems for now for trace:
From what we learned from the ART code, classes prefixed with an H are meant to be arena allocated. However, artist passes extend HOptimizations and therefore should be treated accordingly. But actually using arena allocation there triggers weird crashes such as this one here untangled by ndk-stack from a trace crash without the patch above:
********** Crash dump: **********
29 │ Build fingerprint: 'Android/sdk_phone_x86/generic_x86:7.1.1/NYC/4931657:userdebug/test-keys'
30 │ pid: 13209, tid: 13209, name: main >>> /data/user/0/saarland.cispa.artist.artistgui/files/artist/dex2oat <<<
31 │ signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
32 │ Stack frame #00 pc 001f0345 /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine HOptimization at /proc/self/cwd/art/compiler/optimizing/optimization.h:34
33 │ Stack frame #01 pc 001f1bb1 /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::OptimizingCompiler::Compile(art::DexFile::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, _jobject*, art::DexFile const&,
│ art::Handle<art::mirror::DexCache>) const at /proc/self/cwd/art/compiler/optimizing/optimizing_compiler.cc:857
34 │ Stack frame #02 pc 0014ab2c /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::CompileMethod(art::Thread*, art::CompilerDriver*, art::DexFile::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, _jobject*
│ , art::DexFile const&, art::optimizer::DexToDexCompilationLevel, bool, art::Handle<art::mirror::DexCache>) at /proc/self/cwd/art/compiler/driver/compiler_driver.cc:649
35 │ Stack frame #03 pc 0015e19c /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::CompileClassVisitor::Visit(unsigned int) at /proc/self/cwd/art/compiler/driver/compiler_driver.cc:2710
36 │ Stack frame #04 pc 001595fe /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::ParallelCompilationManager::ForAllClosure::Run(art::Thread*) at /proc/self/cwd/art/compiler/driver/compiler_driver.cc:1957
37 │ Stack frame #05 pc 0055e360 /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart.so: Routine art::ThreadPool::Wait(art::Thread*, bool, bool) at /proc/self/cwd/art/runtime/thread_pool.cc:215
38 │ Stack frame #06 pc 0015260f /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::ParallelCompilationManager::ForAll(unsigned int, unsigned int, art::CompilationVisitor*, unsigned int) at /proc/self/cwd/art/compiler/driver/compiler_d
│ river.cc:1933
39 │ Stack frame #07 pc 00147b3d /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::CompilerDriver::CompileDexFile(_jobject*, art::DexFile const&, std::__1::vector<art::DexFile const*, std::__1::allocator<art::DexFile const*> > const&,
│ art::ThreadPool*, unsigned int, art::TimingLogger*) at /proc/self/cwd/art/compiler/driver/compiler_driver.cc:2750 (discriminator 1)
40 │ Stack frame #08 pc 001463b1 /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libart-compiler.so: Routine art::CompilerDriver::CompileAll(_jobject*, std::__1::vector<art::DexFile const*, std::__1::allocator<art::DexFile const*> > const&, art::TimingLogger*) at /
│ proc/self/cwd/art/compiler/driver/compiler_driver.cc:506
41 │ Stack frame #09 pc 000251d9 /data/data/saarland.cispa.artist.artistgui/files/artist/dex2oat: Routine art::Dex2Oat::Compile() at /proc/self/cwd/art/dex2oat/dex2oat.cc:1710 (discriminator 1)
42 │ Stack frame #10 pc 0000b4eb /data/data/saarland.cispa.artist.artistgui/files/artist/dex2oat: Routine art::CompileApp(art::Dex2Oat&) at /proc/self/cwd/art/dex2oat/dex2oat.cc:2725
43 │ Stack frame #11 pc 0001532c /data/data/saarland.cispa.artist.artistgui/files/artist/lib/libc.so: Routine __libc_init at /proc/self/cwd/bionic/libc/bionic/libc_init_dynamic.cpp:109
44 │ Stack frame #12 pc 0000a272 /data/data/saarland.cispa.artist.artistgui/files/artist/dex2oat: Routine _start at art/dex2oat/dex2oat.cc:?
45 │ Stack frame #13 pc 0000000d <unknown>
So what can we do? I assume that we have some inconsistency in where we use arena allocation and where we use other means of memory management (e.g., smart pointers). Fixing that might solve the problem. For example, there is an arena version of a vector and I am pretty sure we use regular vectors to store H-prefixed objects, such as HInstructions, but this is just a guess.
Anyway, at some point we need to better understand the arena allocation implementation and make sure we use it correctly within artist and the modules to avoid crashes.
Unfortunately, in some cases our modules crash because of what I believe to be inconsistent memory management on our side. More precisely, the trace module for example crashes on x86 if its artist pass is created using a placement
new
operator with the current arena allocator. The following quick-fix solves the problems for now for trace:From what we learned from the ART code, classes prefixed with an
H
are meant to be arena allocated. However, artist passes extendHOptimization
s and therefore should be treated accordingly. But actually using arena allocation there triggers weird crashes such as this one here untangled byndk-stack
from a trace crash without the patch above:So what can we do? I assume that we have some inconsistency in where we use arena allocation and where we use other means of memory management (e.g., smart pointers). Fixing that might solve the problem. For example, there is an arena version of a vector and I am pretty sure we use regular vectors to store
H
-prefixed objects, such asHInstructions
, but this is just a guess.Anyway, at some point we need to better understand the arena allocation implementation and make sure we use it correctly within artist and the modules to avoid crashes.
Affected Projects