Project-ARTist / meta

Meta repository for matters related to more than one repository or even the whole project as such.
2 stars 0 forks source link

Arena allocation crashes #23

Open schrnz opened 5 years ago

schrnz commented 5 years ago

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:

HArtist *TraceModule::createPass(const MethodInfo &method_info) const {
//  return new(method_info.GetGraph()->GetArena()) HTraceArtist(method_info);
  return new HTraceArtist(method_info);
}

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.

Affected Projects