[
https://issues.apache.org/jira/browse/KUDU-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916173#comment-17916173
]
ASF subversion and git services commented on KUDU-3479:
-------------------------------------------------------
Commit d932324e802aa397324c2181dfc55aaee39f4f69 in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=d932324e8 ]
[thirdparty] fix building LLVM/CLANG 11.0.0 with GCC13
GCC13 (G++13) is the default system compiler on contemporary Linux OS
flavors such as Ubuntu 24.04 LTS. With this patch it's now possible
to compile LLVM/CLANG in Kudu's thirdparty on Ubuntu 24.04 and 24.04.1
LTS.
This patch picks up a few relevant updates from the LLVM project's
upstream repository [1] with minor tweaks to adapt to the change in
the source files layout that happened in LLVM/CLANG 12. The updates
prevent the leakage of the parts of the standard library installed
on the build machine into the components of the LLVM/CLANG
that are supposed to be completely freestanding and standalone.
I guess it should help not only with making it possible to build
LLVM/CLANG 11 with GCC13, but also address the root cause of the issues
we have hit on SLES15 and elsewhere in the codegen that's reported in
a few Jira items such as KUDU-3479 and KUDU-3545 [2][3].
However, there might be some extra patches beyond the ones already
included. Anyway, I haven't verified this hypothesis yet.
We definitely need to upgrade from LLVM 11.0.0 to LLVM 19.1.6 and I
suspect it should help us to address [2] and [3] along with other
updates and fixes. However, it's a separate task on its own,
while this patch focuses on making the current version of LLVM/CLANG
in the Kudu's thirdparty buildable on recent Linux OS releases
(such as Ubuntu 24.04 LTS).
I also snuck in an update to skip building compiler-rt tests since
they aren't run in the scope of building LLVM/CLANG as a thirdparty
component of the Apache Kudu project.
[1] https://github.com/llvm/llvm-project
[2] https://issues.apache.org/jira/browse/KUDU-3479
[3] https://issues.apache.org/jira/browse/KUDU-3545
Change-Id: I9b8282c85bbac5f25eae885e4b3ec183104bc540
Reviewed-on: http://gerrit.cloudera.org:8080/22279
Tested-by: Alexey Serbin <[email protected]>
Reviewed-by: Ashwani Raina <[email protected]>
Reviewed-by: Abhishek Chennaka <[email protected]>
> codegen is broken if compiled with GCC11 and newer
> --------------------------------------------------
>
> Key: KUDU-3479
> URL: https://issues.apache.org/jira/browse/KUDU-3479
> Project: Kudu
> Issue Type: Bug
> Components: codegen
> Affects Versions: 1.17.0
> Reporter: Alexey Serbin
> Assignee: Marton Greber
> Priority: Critical
>
> When compiled with GCC11 and newer, Kudu masters and tablet servers are
> crashing. The stack trace of {{kudu-master}} looks like the following:
> {noformat}
> PC: @ 0x7ff822b7cd1d __memmove_avx_unaligned_erms
> *** SIGSEGV (@0x8000) received by PID 189412 (TID 0x7ff81b4d5700) from PID
> 32768; stack trace: ***
> @ 0xe26c81 google::(anonymous namespace)::FailureSignalHandler()
> @ 0x7ff8246298c0 (unknown)
> @ 0x7ff822b7cd1d __memmove_avx_unaligned_erms
> @ 0x7ff824ea20fc (unknown)
> @ 0x132ceeb kudu::tablet::(anonymous
> namespace)::MRSRowProjectorImpl<>::ProjectRowForRead()
> @ 0x132c543 kudu::tablet::MemRowSet::Iterator::FetchRows()
> @ 0x132cb61 kudu::tablet::MemRowSet::Iterator::NextBlock()
> @ 0x2cddb7c kudu::PredicateEvaluatingIterator::NextBlock()
> @ 0x2cde488 kudu::UnionIterator::NextBlock()
> @ 0x12b5a29 kudu::tablet::Tablet::Iterator::NextBlock()
> @ 0xd6dfda kudu::master::SysCatalogTable::ProcessRows<>()
> @ 0xd66cae kudu::master::SysCatalogTable::VisitTables()
> @ 0xddeba8
> kudu::master::MasterPathHandlers::HandleDumpEntities()
> @ 0x1275c2b kudu::Webserver::RunPathHandler()
> @ 0x12767b1 kudu::Webserver::BeginRequestCallback()
> @ 0x12b08fc handle_request
> @ 0x12b377c process_new_connection
> @ 0x12b3e80 worker_thread
> @ 0x7ff82461d6ea start_thread
> @ 0x7ff822b13a6f __GI___clone
> {noformat}
> The litmus test is to run {{codegen-test}} that is crashing with a similar
> stack trace:
> {noformat}
> # ./bin/codegen-test
> [==========] Running 12 tests from 1 test suite.
> [----------] Global test environment set-up.
> [----------] 12 tests from CodegenTest
> [ RUN ] CodegenTest.ObservablesTest
> I0420 17:19:27.839332 175031 test_util.cc:255] Using random seed: -1104489386
> [ OK ] CodegenTest.ObservablesTest (217 ms)
> [ RUN ] CodegenTest.TestEmpty
> I0420 17:19:28.048970 175031 test_util.cc:255] Using random seed: -1104279736
> [ OK ] CodegenTest.TestEmpty (138 ms)
> [ RUN ] CodegenTest.TestKey
> I0420 17:19:28.186726 175031 test_util.cc:255] Using random seed: -1104141979
> [ OK ] CodegenTest.TestKey (125 ms)
> [ RUN ] CodegenTest.TestInts
> I0420 17:19:28.312000 175031 test_util.cc:255] Using random seed: -1104016705
> [ OK ] CodegenTest.TestInts (144 ms)
> [ RUN ] CodegenTest.TestStrings
> I0420 17:19:28.455729 175031 test_util.cc:255] Using random seed: -1103872977
> *** Aborted at 1682011168 (unix time) try "date -d @1682011168" if you are
> using GNU date ***
> PC: @ 0x7f3a14924508 __memmove_evex_unaligned_erms
> *** SIGSEGV (@0x0) received by PID 175031 (TID 0x7f3a1621bcc0) from PID 0;
> stack trace: ***
> @ 0x7c9d92 google::(anonymous namespace)::FailureSignalHandler()
> @ 0x7f3a15c7a8c0 (unknown)
> @ 0x7f3a14924508 __memmove_evex_unaligned_erms
> @ 0x7f3a162c50d4 (unknown)
> @ 0x7b5a0f kudu::CodegenTest::ProjectTestRows<>()
> @ 0x7bc13c kudu::CodegenTest::TestProjection<>()
> @ 0x7ad8ee kudu::CodegenTest_TestStrings_Test::TestBody()
> @ 0x84e517
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x842e86 testing::Test::Run()
> @ 0x842ff5 testing::TestInfo::Run()
> @ 0x8430e5 testing::TestSuite::Run()
> @ 0x84362e testing::internal::UnitTestImpl::RunAllTests()
> @ 0x84e9f7
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x843837 testing::UnitTest::Run()
> @ 0x75876a main
> @ 0x7f3a147ca29d __libc_start_main
> @ 0x7aaf0a _start
> Segmentation fault (core dumped)
> {noformat}
> As a workaround, disable the codegen when running {{kudu-master}} and
> {{kudu-tserver}} processes:
> {noformat}
> --mrs_use_codegen=false
> {noformat}
> Fixing this issue should unblock Kudu adoption on contemporary Linux
> distributions where GCC11 or newer is a system compiler (RH/CentOS 9, Ubuntu
> 22, etc.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)