[ https://issues.apache.org/jira/browse/IMPALA-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754742#comment-17754742 ]
Michael Smith edited comment on IMPALA-11542 at 8/15/23 7:02 PM: ----------------------------------------------------------------- This also shows up consistently during data load with https://jenkins.impala.io/job/ubuntu-20.04-from-scratch-ARM. I've identified a similar case in Julia - https://github.com/JuliaLang/julia/issues/42295 - which they raised with in an LLVM thread - https://discourse.llvm.org/t/problems-with-code-model-large-and-relocations/70511 - without response. A few things I've observed digging into this: * Graviton v2 instances are coded as neoverse-n1, and Graviton v3 instances are neoverse-v1. * LLVM added official support for neoverse-v1 instances in https://github.com/llvm/llvm-project/commit/c2c2cc13601374f987cb03dfc8ef841c64b14024 (LLVM 12+). However neoverse-v1 is not automatically detected until https://github.com/llvm/llvm-project/commit/b92102a6d79f401c1cc8bf7cd0d56e4a6cf90115 (LLVM 14+). Testing with LLVM 12 still results in the same failure on Graviton v3 instances (m7g4xlarge), although I haven't tried overriding the TargetMachine yet. * Data load doesn't fail running Ubuntu with VirtualizationFramework on my Apple M1 MacBook Pro, but this test case does. Setting CodeModel to Small doesn't help. was (Author: JIRAUSER288956): This also shows up consistently during data load with https://jenkins.impala.io/job/ubuntu-20.04-from-scratch-ARM. I've identified a similar case in Julia - https://github.com/JuliaLang/julia/issues/42295 - which they raised with in an LLVM thread - https://discourse.llvm.org/t/problems-with-code-model-large-and-relocations/70511 - without response. A few things I've observed digging into this: * Graviton v2 instances are coded as neoverse-n1, and Graviton v3 instances are neoverse-v1. * LLVM added official support for neoverse-v1 instances in https://github.com/llvm/llvm-project/commit/c2c2cc13601374f987cb03dfc8ef841c64b14024 (LLVM 12+). However neoverse-v1 is not automatically detected until https://github.com/llvm/llvm-project/commit/b92102a6d79f401c1cc8bf7cd0d56e4a6cf90115 (LLVM 14+). Testing with LLVM 12 still results in the same failure on Graviton v3 instances (m7g4xlarge), although I haven't tried overriding the TargetMachine yet. * I don't think I see the same issue running Ubuntu with VirtualizationFramework on my Apple M1 MacBook Pro. Data load succeeds. > TestFailpoints::test_failpoints crash in ARM build > -------------------------------------------------- > > Key: IMPALA-11542 > URL: https://issues.apache.org/jira/browse/IMPALA-11542 > Project: IMPALA > Issue Type: Bug > Components: Backend > Affects Versions: Impala 4.1.0 > Reporter: Quanlong Huang > Assignee: Michael Smith > Priority: Critical > Labels: arm > > Saw the crash in > [https://jenkins.impala.io/job/ubuntu-16.04-from-scratch-ARM/13] > In the ERROR log: > {noformat} > Picked up JAVA_TOOL_OPTIONS: > -agentlib:jdwp=transport=dt_socket,address=30000,server=y,suspend=n > impalad: > /home/ubuntu/native-toolchain/source/llvm/llvm-5.0.1-asserts.src-p3/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:400: > void llvm::RuntimeDyldELF::resolveAArch64Relocation(const > llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t): Assertion > `isInt<33>(Result) && "overflow check failed for relocation"' failed. > Minidump in thread [20013]exec-finstance > (finst:1e4a0f56622f2a15:51c2970900000005) running query > 1e4a0f56622f2a15:51c2970900000000, fragment instance > 1e4a0f56622f2a15:51c2970900000005 > Wrote minidump to > /home/ubuntu/Impala/logs/ee_tests/minidumps/impalad/de4830d8-009d-47f4-f14bb68a-f0d8cd4c.dmp > {noformat} > In the INFO log: > {noformat} > I0830 06:54:49.173234 11329 impala-beeswax-server.cc:516] query: Query { > 01: query (string) = "SELECT STRAIGHT_JOIN *\n FROM alltypes t1\n > JOIN /*+broadcast*/ alltypesagg t2 ON t1.id = t2.id\n > WHERE t2.int_col < 1000", > 03: configuration (list) = list<string>[10] { > [0] = "CLIENT_IDENTIFIE[...](273)", > [1] = "TEST_REPLAN=1", > [2] = "DISABLE_CODEGEN=False", > [3] = "BATCH_SIZE=0", > [4] = "NUM_NODES=0", > [5] = "DISABLE_CODEGEN_ROWS_THRESHOLD=0", > [6] = "MT_DOP=4", > [7] = "ABORT_ON_ERROR=1", > [8] = > "DEBUG_ACTION=4:GETNEXT:MEM_LIMIT_EXCEEDED|COORD_BEFORE_EXEC_RPC:JITTER@100@0.3", > [9] = "EXEC_SINGLE_NODE_ROWS_THRESHOLD=0", > }, > 04: hadoop_user (string) = "ubuntu", > } > ... > 74: client_identifier (string) = > "failure/test_failpoints.py::TestFailpoints::()::test_failpoints[protocol:beeswax|table_format:seq/snap/block|exec_option:{'test_replan':1;'batch_size':0;'num_nodes':0;'disable_codegen_rows_threshold':0;'disable_codegen':False;'abort_on_error':1;'exec_sing", > ... > I0830 06:54:49.173739 11329 Frontend.java:1877] > 1e4a0f56622f2a15:51c2970900000000] Analyzing query: SELECT STRAIGHT_JOIN * > FROM alltypes t1 > JOIN /*+broadcast*/ alltypesagg t2 ON t1.id = t2.id > WHERE t2.int_col < 1000 db: functional_seq_snap {noformat} > The client_identifier shows it's TestFailpoints::test_failpoints. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org