dex2oat crash report

OneKTN816

I have been receiving this crash report for some time in my Pixel 6a
What happens here when it is crashed?

type: crash
osVersion: google/bluejay/bluejay:15/AP4A.241205.013/2024121200:user/release-keys
uid: 1082 (u:r:dex2oat:s0)
cmdline: /apex/com.android.art/bin/dex2oat64 --zip-fd=5 --zip-location=/data/app/~~XLhiisHg8yD3dLbUbaPeYQ==/com.snapwork.hdfc-myspyFu0X8YsrOksgH5PFQ==/base.apk --oat-fd=6 --oat-location=/data/app/~~XLhiisHg8yD3dLbUbaPeYQ==/com.snapwork.hdfc-myspyFu0X8YsrOksgH5PFQ==/oat/arm64/base.odex --output-vdex-fd=7 --swap-fd=8 --class-loader-context-fds=9 --class-loader-context=PCL[]{PCL[/system/framework/org.apache.http.legacy.jar]} --classpath-dir=/data/app/~~XLhiisHg8yD3dLbUbaPeYQ==/com.snapwork.hdfc-myspyFu0X8YsrOksgH5PFQ== --input-vdex-fd=10 --dm-fd=11 --instruction-set=arm64 --instruction-set-features=default --instruction-set-variant=cortex-a76 --compiler-filter=speed --compilation-reason=bg-dexopt --max-image-block-size=524288 --resolve-startup-const-strings=true --generate-mini-debug-info --runtime-arg -Xtarget-sdk-version:33 --runtime-arg -Xhidden-api-policy:enabled --cpu-set=0,1,2,3,4,5 -j6 --runtime-arg -Xms64m --runtime-arg -Xmx512m --comments=app-name:com.snapwork.hdfc,app-version-name:11.2.4,app-version-code:181,art-version:352090000
processUptime: 24s

signal: 11 (SIGSEGV), code 1 (SEGV_MAPERR), faultAddr 30
cause: null pointer dereference
threadName: Compiler driver

backtrace:
    /apex/com.android.art/lib64/libart.so (art::HBasicBlock::AddInstruction(art::HInstruction*)+136, pc 30fb68)
    /apex/com.android.art/lib64/libart.so (void art::HInstructionBuilder::Binop_12x<art::HAnd>(art::Instruction const&, art::DataType::Type, unsigned int)+168, pc 307018)
    /apex/com.android.art/lib64/libart.so (art::HInstructionBuilder::Build()+22708, pc 31e0c4)
    /apex/com.android.art/lib64/libart.so (art::HGraphBuilder::BuildGraph()+352, pc 30bad0)
    /apex/com.android.art/lib64/libart.so (art::HInliner::TryBuildAndInlineHelper(art::HInvoke*, art::ArtMethod*, art::ReferenceTypeInfo, art::HInstruction**, bool)+1156, pc 27c104)
    /apex/com.android.art/lib64/libart.so (art::HInliner::TryInline(art::HInvoke*)+5088, pc 276780)
    /apex/com.android.art/lib64/libart.so (art::HInliner::Run()+1092, pc 275374)
    /apex/com.android.art/lib64/libart.so (art::HInliner::TryBuildAndInlineHelper(art::HInvoke*, art::ArtMethod*, art::ReferenceTypeInfo, art::HInstruction**, bool)+5452, pc 27d1cc)
    /apex/com.android.art/lib64/libart.so (art::HInliner::TryInline(art::HInvoke*)+5088, pc 276780)
    /apex/com.android.art/lib64/libart.so (art::HInliner::Run()+1092, pc 275374)
    /apex/com.android.art/lib64/libart.so (art::OptimizingCompiler::RunOptimizations(art::HGraph*, art::CodeGenerator*, art::DexCompilationUnit const&, art::PassObserver*, art::OptimizationDef const*, unsigned long) const+196, pc 34bec4)
    /apex/com.android.art/lib64/libart.so (art::OptimizingCompiler::TryCompile(art::ArenaAllocator*, art::ArenaStack*, art::DexCompilationUnit const&, art::ArtMethod*, art::CompilationKind, art::VariableSizedHandleScope*) const+2048, pc 349e60)
    /apex/com.android.art/lib64/libart.so (art::OptimizingCompiler::Compile(art::dex::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::Handle<art::mirror::DexCache>) const+776, pc 49f468)
    /apex/com.android.art/bin/dex2oat64 (art::CompileMethodQuick(art::Thread*, art::CompilerDriver*, art::dex::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::Handle<art::mirror::DexCache>, unsigned short)+2016, pc 87aa0)
    /apex/com.android.art/bin/dex2oat64 (art::ParallelCompilationManager::ForAllClosureLambda<void art::CompileDexFile<void (*)(art::Thread*, art::CompilerDriver*, art::dex::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::Handle<art::mirror::DexCache>, unsigned short)>(art::CompilerDriver*, _jobject*, art::DexFile const&, art::ThreadPool*, unsigned long, art::TimingLogger*, char const*, void (*)(art::Thread*, art::CompilerDriver*, art::dex::CodeItem const*, unsigned int, art::InvokeType, unsigned short, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::Handle<art::mirror::DexCache>, unsigned short))::'lambda'(unsigned long)>::Run(art::Thread*)+3268, pc 92eb4)
    /apex/com.android.art/lib64/libart.so (art::ThreadPoolWorker::Run()+280, pc 5caba8)
    /apex/com.android.art/lib64/libart.so (art::ThreadPoolWorker::Callback(void*)+164, pc 586e14)
    /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+132, pc 75d34)
    /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64, pc 66890)

de0u

OneKTN816 This was previously reported as Issue #4328. It appears this incident is related to the same app as the one in the existing report.

I have added your report to the issue.

GrapheneOS

This is an upstream bug in the ART compiler. It's a null pointer dereference which would also be caught by the stock OS in the same way, but it's possible that it's due to a use-after-free bug and it's only null due to zero-on-free on GrapheneOS. It would be helpful if someone could try this app on an 8th or 9th generation Pixel to see if there's a use-after-free access detected by hardware memory tagging. The pointer may be null due to the zero-on-free feature which uses zero rather than another value because it tends to be safest and results in pointers hitting the reserved space at the start of the address space in practice even if there's an offset from them as there is in this case.

The ART compiler is crashing while trying to compile the app. It will likely occur each time it tries. The stock OS only does ahead-of-time compilation in the background rather than for app installs/updates and OS updates. They also only compile parts of the app marked as heavily used by the interpreter and in-memory JIT compiler. If it does crash on the stock OS, users won't receive a notification. All of these crash notifications are a feature we added so users can see there's a crash and report an issue to us or to an app developer. Therefore, it's unclear if it happens on the stock OS when it compiles apps in the background. It would potentially happen if it compiled the same code, but it might not if the issue that's being triggered is a use-after-free because they don't do zero-on-free for performance reasons while we always do it for the whole base OS and do it for third party apps unless people disable hardened_malloc for an app.