[jira] [Updated] (ARROW-4247) [Packaging] Update verify script for 0.12.0
[ https://issues.apache.org/jira/browse/ARROW-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ARROW-4247: -- Labels: pull-request-available (was: ) > [Packaging] Update verify script for 0.12.0 > --- > > Key: ARROW-4247 > URL: https://issues.apache.org/jira/browse/ARROW-4247 > Project: Apache Arrow > Issue Type: Improvement > Components: Packaging >Reporter: Kouhei Sutou >Assignee: Kouhei Sutou >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARROW-4247) [Packaging] Update verify script for 0.12.0
Kouhei Sutou created ARROW-4247: --- Summary: [Packaging] Update verify script for 0.12.0 Key: ARROW-4247 URL: https://issues.apache.org/jira/browse/ARROW-4247 Project: Apache Arrow Issue Type: Improvement Components: Packaging Reporter: Kouhei Sutou Assignee: Kouhei Sutou -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARROW-4246) [Plasma][Python] PlasmaClient.list doesn't work with CUDA enabled Plasma
Kouhei Sutou created ARROW-4246:
---
Summary: [Plasma][Python] PlasmaClient.list doesn't work with CUDA
enabled Plasma
Key: ARROW-4246
URL: https://issues.apache.org/jira/browse/ARROW-4246
Project: Apache Arrow
Issue Type: Bug
Components: Python
Affects Versions: 0.12.0
Reporter: Kouhei Sutou
{{plasma::ObjectTableEntry}} layout is changed with CUDA enabled build:
https://github.com/apache/arrow/blob/master/cpp/src/plasma/common.h#L97-L100
But it's not cared in Cython code:
https://github.com/apache/arrow/blob/master/python/pyarrow/_plasma.pyx#L77-L78
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
>
[jira] [Commented] (ARROW-4228) [GLib] Add garrow_list_data_type_get_field()
[
https://issues.apache.org/jira/browse/ARROW-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741438#comment-16741438
]
Yosuke Shiro commented on ARROW-4228:
-
Thanks for posting your comments. I'll work on this today.
> [GLib] Add garrow_list_data_type_get_field()
>
>
> Key: ARROW-4228
> URL: https://issues.apache.org/jira/browse/ARROW-4228
> Project: Apache Arrow
> Issue Type: Improvement
> Components: GLib
>Reporter: Kouhei Sutou
>Assignee: Yosuke Shiro
>Priority: Major
> Fix For: 0.13.0
>
>
> And make {{garrow_list_data_type_get_value_field()}} deprecated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741439#comment-16741439
]
Michael Vilim commented on ARROW-4242:
--
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 0x (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 std::allocator,
> (_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
>
[jira] [Comment Edited] (ARROW-4228) [GLib] Add garrow_list_data_type_get_field()
[
https://issues.apache.org/jira/browse/ARROW-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741410#comment-16741410
]
Kouhei Sutou edited comment on ARROW-4228 at 1/12/19 9:19 PM:
--
Yes. We should add these macros.
We also need to add symbol list entry for 0.13.0 to
{{c_glib/arrow-glib/arrow-glib-docs.xml}}.
We don't need to change version in {{meson.build}} and {{configure.ac}}. It's
done in release process.
was (Author: kou):
Yes. We should add these macros.
We also need to add symbol list entry for 0.13.0 to
\{c_glib/arrow-glib/arrow-glib-docs.xml}.
We don't need to change version in \{meson.build} and \{configure.ac}. It's
done in release process.
> [GLib] Add garrow_list_data_type_get_field()
>
>
> Key: ARROW-4228
> URL: https://issues.apache.org/jira/browse/ARROW-4228
> Project: Apache Arrow
> Issue Type: Improvement
> Components: GLib
>Reporter: Kouhei Sutou
>Assignee: Yosuke Shiro
>Priority: Major
> Fix For: 0.13.0
>
>
> And make {{garrow_list_data_type_get_value_field()}} deprecated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARROW-4228) [GLib] Add garrow_list_data_type_get_field()
[
https://issues.apache.org/jira/browse/ARROW-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741410#comment-16741410
]
Kouhei Sutou commented on ARROW-4228:
-
Yes. We should add these macros.
We also need to add symbol list entry for 0.13.0 to
\{c_glib/arrow-glib/arrow-glib-docs.xml}.
We don't need to change version in \{meson.build} and \{configure.ac}. It's
done in release process.
> [GLib] Add garrow_list_data_type_get_field()
>
>
> Key: ARROW-4228
> URL: https://issues.apache.org/jira/browse/ARROW-4228
> Project: Apache Arrow
> Issue Type: Improvement
> Components: GLib
>Reporter: Kouhei Sutou
>Assignee: Yosuke Shiro
>Priority: Major
> Fix For: 0.13.0
>
>
> And make {{garrow_list_data_type_get_value_field()}} deprecated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARROW-4245) [Rust] Add Rustdoc header to each source file
Andy Grove created ARROW-4245: - Summary: [Rust] Add Rustdoc header to each source file Key: ARROW-4245 URL: https://issues.apache.org/jira/browse/ARROW-4245 Project: Apache Arrow Issue Type: Improvement Components: Rust Reporter: Andy Grove Fix For: 0.13.0 Each source file should contain a rustdoc header giving a summary of the contents of the file. This will make the documentation hosted on docs.rs much more useful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741300#comment-16741300
]
Francois Saint-Jacques commented on ARROW-4242:
---
My guess would be that one dependency was compiled with gcc7 & libstdc++ of the
same version, then you compile with gcc-8 and link with a newer libstdc++.
> [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 0x (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 std::allocator,
> (_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 (gnu_cxx::_Lock_policy)2>::_shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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
> std::allocate_shared
> >(std::allocator 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
> std::make_shared()
>
[jira] [Commented] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741299#comment-16741299
]
Francois Saint-Jacques commented on ARROW-4242:
---
Reminds me of collision linking different libstdc++ as reported with
tensorflow/torch. See https://github.com/apache/arrow/issues/2637
> [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 0x (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 std::allocator,
> (_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 (gnu_cxx::_Lock_policy)2>::_shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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
> std::allocate_shared
> >(std::allocator 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
> std::make_shared()
>
[jira] [Comment Edited] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741296#comment-16741296
]
Michael Vilim edited comment on ARROW-4242 at 1/12/19 2:02 PM:
---
GCC 7 works without a problem.
Dockerfile:
{noformat}
FROM archimg/base
RUN \
pacman -Sy --noconfirm git cmake gcc7 make boost autoconf python; \
git clone --recursive https://github.com/apache/arrow.git; \
export CC=/usr/bin/gcc-7; \
export CXX=/usr/bin/g++-7; \
cd arrow/cpp; \
mkdir build; \
cd build; \
cmake -DARROW_BUILD_TESTS=ON ..; \
make
{noformat}
{noformat}
docker build -t mvilim/arch_arrow_test_segfault7 .
docker run mvilim/arch_arrow_test_segfault7 /bin/bash -c "cd /arrow/cpp/build;
make unittest; gcc-7 --version; cmake --version"
{noformat}
was (Author: mvilim):
GCC 7 works without a problem.
Dockerfile:
{noformat}
FROM archimg/base
RUN \
pacman -Sy --noconfirm git cmake gcc7 make boost autoconf python; \
git clone --recursive https://github.com/apache/arrow.git; \
export CC=/usr/bin/gcc-7; \
export CXX=/usr/bin/g++-7; \
cd arrow/cpp; \
mkdir build; \
cd build; \
cmake -DARROW_BUILD_TESTS=ON ..; \
make
{noformat}
{noformat}
docker build -t mvilim/arch_arrow_test_segfault7 .
docker run mvilim/arch_arrow_test_segfault7 /bin/bash -c "cd /arrow/cpp/build;
make unittest; gcc --version; cmake --version"
{noformat}
> [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 0x (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 std::allocator,
> (_gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)
>
[jira] [Commented] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741296#comment-16741296
]
Michael Vilim commented on ARROW-4242:
--
GCC 7 works without a problem.
Dockerfile:
{noformat}
FROM archimg/base
RUN \
pacman -Sy --noconfirm git cmake gcc7 make boost autoconf python; \
git clone --recursive https://github.com/apache/arrow.git; \
export CC=/usr/bin/gcc-7; \
export CXX=/usr/bin/g++-7; \
cd arrow/cpp; \
mkdir build; \
cd build; \
cmake -DARROW_BUILD_TESTS=ON ..; \
make
{noformat}
{noformat}
docker build -t mvilim/arch_arrow_test_segfault7 .
docker run mvilim/arch_arrow_test_segfault7 /bin/bash -c "cd /arrow/cpp/build;
make unittest; gcc --version; cmake --version"
{noformat}
> [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 0x (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 std::allocator,
> (_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 (gnu_cxx::_Lock_policy)2>::_shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator const&)
>
[jira] [Updated] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vilim updated ARROW-4242:
-
Attachment: Dockerfile
> [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 0x (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 std::allocator,
> (_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 (gnu_cxx::_Lock_policy)2>::_shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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
> std::allocate_shared
> >(std::allocator 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
> std::make_shared()
> /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
[jira] [Updated] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vilim updated ARROW-4242:
-
Attachment: (was: Dockerfile)
> [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 0x (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 std::allocator,
> (_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 (gnu_cxx::_Lock_policy)2>::_shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
> >(std::_Sp_make_shared_tag, std::allocator 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
> std::allocate_shared
> >(std::allocator 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
> std::make_shared()
> /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
[jira] [Updated] (ARROW-4242) [C++] Seg fault when running unit tests on fresh Arch Linux install
[
https://issues.apache.org/jira/browse/ARROW-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vilim updated ARROW-4242:
-
Description:
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 0x (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,
(_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::_shared_ptr
>(std::_Sp_make_shared_tag, std::allocator 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::shared_ptr
>(std::_Sp_make_shared_tag, std::allocator 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
std::allocate_shared
>(std::allocator 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
std::make_shared()
/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
std::make_shared, std::allocator > const&,
std::shared_ptr const&, bool&,
std::shared_ptr
const&>(std::_cxx11::basic_string,
std::allocator > const&, std::shared_ptr const&, bool&,
std::shared_ptr 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, std::allocator > const&,
std::shared_ptr const&, bool,
[jira] [Commented] (ARROW-3578) [Release] Address spurious Apache RAT failures in source release script
[ https://issues.apache.org/jira/browse/ARROW-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741242#comment-16741242 ] Krisztian Szucs commented on ARROW-3578: Caused by the prepare script: [https://github.com/apache/arrow/blob/master/dev/release/00-prepare.sh#L147-L171] On the release branch the rat exclude file is updated, and the 02-source.sh uses the updated exclude file, not the one which belongs to the release. Here is the boundary: [https://github.com/apache/arrow/blob/master/dev/release/00-prepare.sh#L141] So We need to run RAT with the exclude file within the archive. > [Release] Address spurious Apache RAT failures in source release script > --- > > Key: ARROW-3578 > URL: https://issues.apache.org/jira/browse/ARROW-3578 > Project: Apache Arrow > Issue Type: Bug > Components: Developer Tools >Reporter: Wes McKinney >Priority: Blocker > Fix For: 0.13.0 > > > Something about the untarring / retarring process is offending Apache RAT and > it's reporting a number of unapproved licenses incorrectly > https://gist.github.com/wesm/490dc50c494cc914ae28b4fd897a73eb -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARROW-4243) [Python] Test failure with pandas 0.24.0rc1
[ https://issues.apache.org/jira/browse/ARROW-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krisztian Szucs reassigned ARROW-4243: -- Assignee: Kouhei Sutou > [Python] Test failure with pandas 0.24.0rc1 > --- > > Key: ARROW-4243 > URL: https://issues.apache.org/jira/browse/ARROW-4243 > Project: Apache Arrow > Issue Type: Improvement > Components: Python >Reporter: Kouhei Sutou >Assignee: Kouhei Sutou >Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARROW-4243) [Python] Test failure with pandas 0.24.0rc1
[ https://issues.apache.org/jira/browse/ARROW-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krisztian Szucs resolved ARROW-4243. Resolution: Fixed Fix Version/s: 0.12.0 Issue resolved by pull request 3387 [https://github.com/apache/arrow/pull/3387] > [Python] Test failure with pandas 0.24.0rc1 > --- > > Key: ARROW-4243 > URL: https://issues.apache.org/jira/browse/ARROW-4243 > Project: Apache Arrow > Issue Type: Improvement > Components: Python >Reporter: Kouhei Sutou >Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARROW-4239) [Release] Updating .deb package names in the prepare script failed to run on OSX
[ https://issues.apache.org/jira/browse/ARROW-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krisztian Szucs resolved ARROW-4239. Resolution: Fixed Fix Version/s: 0.12.0 Issue resolved by pull request 3385 [https://github.com/apache/arrow/pull/3385] > [Release] Updating .deb package names in the prepare script failed to run on > OSX > > > Key: ARROW-4239 > URL: https://issues.apache.org/jira/browse/ARROW-4239 > Project: Apache Arrow > Issue Type: Task > Components: Packaging >Reporter: Krisztian Szucs >Assignee: Kouhei Sutou >Priority: Major > Labels: pull-request-available > Fix For: 0.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > > This code segment: > [https://github.com/apache/arrow/blob/master/dev/release/00-prepare.sh#L143-L167] > > It was complaining about missing files, so something with the pattern is > wrong on OSX: > [https://github.com/apache/arrow/blob/master/dev/release/00-prepare.sh#L148] > > Additionally the problem can be twofold, depending on the outcome of the RC0. > If it passes the VOTE, than We need to run the previous update script, > similarly like [~kou] did after 0.11.0 release: > https://github.com/apache/arrow/commit/222632c67464a2bdd4724161c5ae79abf72a8bf7#diff-2294062bc9761f012d9abea73fa86153 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARROW-4244) Clarify language around padding/alignment
[ https://issues.apache.org/jira/browse/ARROW-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ARROW-4244: -- Labels: pull-request-available (was: ) > Clarify language around padding/alignment > - > > Key: ARROW-4244 > URL: https://issues.apache.org/jira/browse/ARROW-4244 > Project: Apache Arrow > Issue Type: Bug > Components: Documentation >Reporter: Micah Kornfield >Assignee: Micah Kornfield >Priority: Minor > Labels: pull-request-available > > The recommendation on padding an alignment reads a little bit strangely, I'm > going to take a stab at rewording is slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
