[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741439#comment-16741439
]
Michael Vilim edited comment on ARROW-4242 at 1/13/19 1:53 AM:
---------------------------------------------------------------
I tried analyzing the linking of dependencies, removing the dependencies
entirely, and compiling the dependencies from source (to ensure the same
libstdc++ was used). I was not able to find anything that worked.
I then tried to start from a minimally working simple Arrow executable test and
add back in pieces of the normal CMake build. I eventually narrowed down a
change that caused it to break. Commenting out the std::*; in
cpp/src/arrow/symbols.map fixed the issue in the original tests. To be honest,
I don't really understand why.
I am able to reproduce the behavior change of disabling exporting of std::*
between GCC 7 and GCC 8 on Arch Linux independent of Arrow (using a very simple
program with a shared library that passes a shared_ptr to a main function). A
set of scripts that show this can be found here:
[https://github.com/mvilim/gcc-symbol-map-test] I have no idea whether this is
an issue with GCC, Arch Linux (something like mixed GCC libraries?), or whether
the symbol map should not be used in the way it is (declaring std::* as local).
was (Author: mvilim):
I tried analyzing the linking of dependencies, removing the dependencies
entirely, and compiling the dependencies from source (to ensure the same
libstdc++ was used). I was not able to find anything that worked.
I then tried to start from a minimally working simple Arrow executable test and
add back in pieces of the normal CMake build. I eventually narrowed down a
change that caused it to break. Commenting out the std::*; in
cpp/src/arrow/symbols.map fixed the issue in the original tests. To be honest,
I don't really understand why.
I am able to reproduce the behavior change of disabling exporting of std::*
between GCC 7 and GCC 8 on Arch Linux independent of Arrow (using a very simple
program with a shared library that passes a shared_ptr to a main function). A
set of scripts that show this can be found here:
[https://github.com/mvilim/gcc-symbol-map-test|https://github.com/mvilim/gcc-symbol-map-test]
I have no idea whether this is an issue with GCC versions, Arch Linux
(something like mixed GCC libraries?), or whether the symbol map should not be
used in the way it is (declaring std::* as local).
> [C++] Seg fault when running unit tests on fresh Arch Linux install
> -------------------------------------------------------------------
>
> Key: ARROW-4242
> URL: https://issues.apache.org/jira/browse/ARROW-4242
> Project: Apache Arrow
> Issue Type: Bug
> Components: C++
> Environment: Arch Linux x86-64
> Reporter: Michael Vilim
> Priority: Minor
> Attachments: Dockerfile
>
>
> First, let me say I appreciate all the work that has been put into this
> project. I have been following it with great interest and recently decided to
> include it in one of my projects.
> However, I have run into an issue with a segmentation fault when trying to
> run the C++ unit tests (which previously worked for me). This issue appears
> to be something specific to my system (I am running Arch Linux). I can
> reproduce the issue with the minimal Docker install of Arch:
> {noformat}
> FROM archimg/base
> RUN \
> pacman -Sy --noconfirm git cmake gcc make boost autoconf python; \
> git clone --recursive https://github.com/apache/arrow.git; \
> cd arrow/cpp; \
> mkdir build; \
> cd build; \
> cmake -DARROW_BUILD_TESTS=ON ..; \
> make
> {noformat}
> If you create a Dockerfile with those contents and then run
> {noformat}
> docker build -t mvilim/arch-arrow-test-segfault .
> docker run mvilim/arch-arrow-test-segfault /bin/bash -c "cd /arrow/cpp/build;
> make unittest; gcc --version; cmake --version"{noformat}
> you should be able to reproduce the issue:
> {noformat}
> The following tests FAILED:
> 2 - arrow-array-test (Failed)
> 3 - arrow-buffer-test (Failed)
> 8 - arrow-stl-test (Failed)
> 9 - arrow-type-test (Failed)
> 10 - arrow-table-test (Failed)
> 15 - arrow-compute-boolean-test (Failed)
> 16 - arrow-compute-cast-test (Failed)
> 17 - arrow-compute-hash-test (Failed)
> 18 - arrow-feather-test (Failed)
> 19 - arrow-ipc-read-write-test (Failed)
> 20 - arrow-ipc-json-simple-test (Failed)
> 21 - arrow-ipc-json-test (Failed)
> 24 - arrow-csv-column-builder-test (Failed)
> 28 - arrow-io-compressed-test (Failed)
> 31 - arrow-io-memory-test (Failed){noformat}
> If you run the container interactively and inspect the logs, you will see
> that all the failures are caused by seg faults.
> I used git bisect to narrow the problem down to commit 7cdab9b06 when the
> tests were switched to use shared linking by default. Static linking works
> fine for me (using -DARROW_TEST_LINKAGE=static).
> I also compiled with Clang and -DARROW_USE_ASAN=ON and inspected several of
> the stack traces. It looks like all the seg faults happen during creation of
> a shared pointer, but in varied places.
> On creation of Int32Type:
> {noformat}
> ./debug/arrow-array-test
> AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==29563==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
> 0x558afa951b70 bp 0x7ffcf1c34880 sp 0x7ffcf1c34810 T0)
> ==29563==The signal is caused by a READ memory access.
> ==29563==Hint: address points to the zero page.
> #0 0x558afa951b6f in std::type_info::operator==(std::type_info const&) const
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/typeinfo:123:12
> #1 0x558afa9b2c16 in std::Sp_counted_ptr_inplace<arrow::Int32Type,
> std::allocator<arrow::Int32Type>,
> (_gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr_base.h:573:16
> #2 0x7fe7b711e6f1 in
> std::_shared_count<(_gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> const&) const
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr_base.h:751:31
> #3 0x7fe7b73ec240 in std::_shared_ptr<arrow::Int32Type,
> (gnu_cxx::_Lock_policy)2>::_shared_ptr<std::allocator<arrow::Int32Type>
> >(std::_Sp_make_shared_tag, std::allocator<arrow::Int32Type> const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr_base.h:1328:28
> #4 0x7fe7b73ec1c7 in
> std::shared_ptr<arrow::Int32Type>::shared_ptr<std::allocator<arrow::Int32Type>
> >(std::_Sp_make_shared_tag, std::allocator<arrow::Int32Type> const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr.h:360:4
> #5 0x7fe7b73ec14b in std::shared_ptr<arrow::Int32Type>
> std::allocate_shared<arrow::Int32Type, std::allocator<arrow::Int32Type>
> >(std::allocator<arrow::Int32Type> const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr.h:706:14
> #6 0x7fe7b73cd323 in std::shared_ptr<arrow::Int32Type>
> std::make_shared<arrow::Int32Type>()
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr.h:722:14
> #7 0x7fe7b73c3f2f in arrow::int32()
> /home/mvilim/repos/arrow/cpp/src/arrow/type.cc:484:1
> #8 0x558afa76cc8d in __cxx_global_var_init.1
> /home/mvilim/repos/arrow/cpp/src/arrow/ipc/test-common.h:65:30
> #9 0x558afa779ef9 in GLOBAL_sub_I_array_test.cc
> /home/mvilim/repos/arrow/cpp/src/arrow/array-test.cc{noformat}
> On creation of a Field:
> {noformat}
> #6 0x7f74f1947598 in std::shared_ptr<arrow::Field>
> std::make_shared<arrow::Field, std::_cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::shared_ptr<arrow::DataType> const&, bool&,
> std::shared_ptr<arrow::KeyValueMetadata const>
> const&>(std::_cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&, std::shared_ptr<arrow::DataType> const&,
> bool&, std::shared_ptr<arrow::KeyValueMetadata const> const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr.h:722:14
> #7 0x7f74f193e1e3 in arrow::field(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::shared_ptr<arrow::DataType> const&, bool,
> std::shared_ptr<arrow::KeyValueMetadata const> const&)
> /home/mvilim/repos/arrow/cpp/src/arrow/type.cc:556:10
> #8 0x56079cb90206 in
> arrow::TestField_TestMetadataConstruction_Test::TestBody()
> /home/mvilim/repos/arrow/cpp/src/arrow/type-test.cc:68:13{noformat}
> On creation of an Array:
> {noformat}
> #6 0x7f8da9f9300f in std::shared_ptr<arrow::NumericArray<arrow::Int32Type> >
> std::make_shared<arrow::NumericArray<arrow::Int32Type>,
> std::shared_ptr<arrow::ArrayData> const&>(std::shared_ptr<arrow::ArrayData>
> const&)
> /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/bits/shared_ptr.h:722:14
> #7 0x7f8da9f86fc2 in arrow::Status
> arrow::internal::ArrayDataWrapper::Visit<arrow::Int32Type>(arrow::Int32Type
> const&) /home/mvilim/repos/arrow/cpp/src/arrow/array.cc:892:13
> #8 0x7f8da9f5a076 in arrow::Status
> arrow::VisitTypeInline<arrow::internal::ArrayDataWrapper>(arrow::DataType
> const&, arrow::internal::ArrayDataWrapper*)
> /home/mvilim/repos/arrow/cpp/src/arrow/visitor_inline.h:46:5
> #9 0x7f8da9f2f3d3 in arrow::MakeArray(std::shared_ptr<arrow::ArrayData>
> const&) /home/mvilim/repos/arrow/cpp/src/arrow/array.cc:905:14{noformat}
> GCC version is 8.2.1 20181127
> cmake version is 3.13.2
> I believe the issue is related to linking in some way (because this does not
> happen with static linking). It is probably my lack of experience in C++
> showing, but I am unsure how to proceed in finding the cause of this issue.
> Any help or advice would be appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
