niyue commented on PR #39098:
URL: https://github.com/apache/arrow/pull/39098#issuecomment-1852177839
With my current macOS + Docker + Rosetta setup, I did some more experiments
today, and I slightly modified the `ubuntu-22.04-cpp.dockerfile` to create an
`ubuntu-23.10-cpp.dockerfile`, and install LLVM 16 and 17 for verification, and
I found:
1) LLVM 16 reported similar error as LLVM 14 (under Ubuntu 22.04), with
slightly different stack trace (the `#0` stack is now `memcpy`, may be caused
by different version of address sanitizer in LLVM)
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==46227==ERROR: AddressSanitizer: SEGV on unknown address 0x200071e56200 (pc
0x55555597eb3a bp 0x5554ffffd280 sp 0x5554ffffca40 T0)
==46227==The signal is caused by a READ memory access.
#0 0x55555597eb3a in memcpy
(/build/cpp/debug/gandiva-internals-test+0x42ab3a) (BuildId:
30f326eec529ed661b538f9254c6b415894cb6d3)
#1 0x7fffdc6b8d39 in
llvm::RuntimeDyldImpl::emitSection(llvm::object::ObjectFile const&,
llvm::object::SectionRef const&, bool)
(/usr/lib/llvm-16/lib/libLLVM-16.so.1+0x2aded39) (BuildId:
08068dfc9a0c80774489feea5c7df0a25abf4ced)
#2 0x7fffdc6b7e02 in
llvm::RuntimeDyldImpl::findOrEmitSection(llvm::object::ObjectFile const&,
llvm::object::SectionRef const&, bool, std::map<llvm::object::SectionRef,
unsigned int, std::less<llvm::object::SectionRef>,
std::allocator<std::pair<llvm::object::SectionRef const, unsigned int>>>&)
(/usr/lib/llvm-16/lib/libLLVM-16.so.1+0x2adde02) (BuildId:
08068dfc9a0c80774489feea5c7df0a25abf4ced)
#3 0x7fffdc6b6580 in
llvm::RuntimeDyldImpl::loadObjectImpl(llvm::object::ObjectFile const&)
(/usr/lib/llvm-16/lib/libLLVM-16.so.1+0x2adc580) (BuildId:
08068dfc9a0c80774489feea5c7df0a25abf4ced)
#4 0x7fffdc6c9bb5 in
llvm::RuntimeDyldELF::loadObject(llvm::object::ObjectFile const&)
(/usr/lib/llvm-16/lib/libLLVM-16.so.1+0x2aefbb5) (BuildId:
08068dfc9a0c80774489feea5c7df0a25abf4ced)
#5 0x7fffdc6baf57 in
llvm::RuntimeDyld::loadObject(llvm::object::ObjectFile const&)
(/usr/lib/llvm-16/lib/libLLVM-16.so.1+0x2ae0f57) (BuildId:
08068dfc9a0c80774489feea5c7df0a25abf4ced)
```
2) LLVM 17 doesn't report any error. Namely, the same code branch
`feature/orc-v2-jit`, when compiled and run in LLVM 17 (Ubuntu 23.10), the ASAN
issue is gone, and all tests passed without any failure or error. I verified
the binary is indeed compiled with ASAN enabled by running `nm
./debug/gandiva-internals-test | grep asan`
It seems the issue in my local env is probably a LLJIT/LLVM ASAN issue, and
I am not sure if it affects the functionality in this case.
But since I am not able to reproduce the exactly same issue in CI, I am not
sure the issue in my local env has the same cause of the issue in CI.
@kou, is it possible for your to use LLVM 17 and Ubuntu 23.10 to see how
things will turn out, alternatively, if I want to add a new check env `LLVM 17
+ Ubuntu 23.10` in CI, which part of configuration should I change? Thanks.
### steps to create the 23.10 docker image for testing
1) copy `ubuntu-22.04-cpp.dockerfile` to `ubuntu-23.10-cpp.dockerfile`
2) change the base image from `22.04` to `23.10`
3) install an additional `libclang-rt-${clang_tools}-dev` package for
sanitizer
4) install `libboost-filesystem1.81-dev` and `libboost-system1.81-dev` to
use boost 1.81 instead of 1.74
5) disable `install_gcs_testbench.sh` script (its installation failed so I
simply remove it during my verification)
6) `LLVM=17 CLANG_TOOLS=17 UBUNTU=23.10 archery docker run
ubuntu-cpp-sanitizer bash` to run and verify manually
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
