[
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.
[[email protected]]
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.
[[email protected]]
> [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)
