You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Antoine Pitrou (Jira)" <ji...@apache.org> on 2019/09/12 11:02:00 UTC
[jira] [Comment Edited] (ARROW-6547) [C++] valgrind errors in
arrow-ipc-read-write-test
[ https://issues.apache.org/jira/browse/ARROW-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928444#comment-16928444 ]
Antoine Pitrou edited comment on ARROW-6547 at 9/12/19 11:01 AM:
-----------------------------------------------------------------
Without jemalloc I get Valgrind failures in three tests (note I disabled Plasma and Gandiva):
{code}
37 - arrow-diff-test (Failed)
44 - arrow-s3fs-test (Failed)
64 - arrow-flight-test (Failed)
{code}
{{arrow-diff-test}} is because of the way we read and compare boolean arrays ("Conditional jump or move depends on uninitialised value(s)"). Not sure it's reasonable to do something about it.
{{arrow-flight-test}} is both with memory leaks inside gRPC (perhaps not severe, some initialization data it seems) and processing uninitialized data inside OpenSSL. The latter may be a false positive (OpenSSL is known to not mix well with Valgrind), but perhaps also points to our Flight tests sending uninitialized data over the wire (though I doubt so, otherwise we'd have errors in IPC tests as well?).
{{arrow-s3fs-test}} is some unimportant stuff in OpenSSL and boost::process ("Conditional jump or move depends on uninitialised value(s)").
This reminds me that getting clean Valgrind builds is tedious, especially with non-trivial dependencies. ASAN (enabled on one of the Travis jobs AFAIR) seems to serve us better.
[~emkornfield@gmail.com]
was (Author: pitrou):
Without jemalloc I get Valgrind failures in three tests (note I disabled Plasma and Gandiva):
{code}
37 - arrow-diff-test (Failed)
44 - arrow-s3fs-test (Failed)
64 - arrow-flight-test (Failed)
{code}
{{arrow-diff-test}} is because of the way we read and compare boolean arrays ("Conditional jump or move depends on uninitialised value(s)"). Not sure it's reasonable to do something about it.
{{arrow-flight-test}} is both with memory leaks inside gRPC (perhaps not severe, some initialization data it seems) and processing uninitialized data inside OpenSSL. The latter may be a false positive (OpenSSL is known to not mix well with Valgrind), but perhaps also points to our Flight tests sending uninitialized data over the wire (though I doubt so, otherwise we'd have errors in IPC tests as well?).
{{arrow-s3fs-test}} is some important stuff in OpenSSL and boost::process ("Conditional jump or move depends on uninitialised value(s)").
This reminds me that getting clean Valgrind builds is tedious, especially with non-trivial dependencies. ASAN (enabled on one of the Travis jobs AFAIR) seems to serve us better.
[~emkornfield@gmail.com]
> [C++] valgrind errors in arrow-ipc-read-write-test
> --------------------------------------------------
>
> Key: ARROW-6547
> URL: https://issues.apache.org/jira/browse/ARROW-6547
> Project: Apache Arrow
> Issue Type: Bug
> Components: C++
> Reporter: Wes McKinney
> Priority: Major
> Fix For: 0.15.0
>
>
> Not sure when these crept in but I encountered when looking into a segfault in a build today
> https://gist.github.com/wesm/b388dda4f0e2e38a8aa77dfc9bd91914
--
This message was sent by Atlassian Jira
(v8.3.2#803003)