You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Dewey Dunnington (Jira)" <ji...@apache.org> on 2022/03/07 14:28:00 UTC
[jira] [Commented] (ARROW-15656) [C++] [R] Valgrind error with C-data interface
[ https://issues.apache.org/jira/browse/ARROW-15656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502305#comment-17502305 ]
Dewey Dunnington commented on ARROW-15656:
------------------------------------------
The valgrind job still seems to be failing...it seems like the errors are in {{ExecNode_scan}} and in {{schema_}}.
https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=20853&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181&l=12604
https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=20853&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181&l=12698
> [C++] [R] Valgrind error with C-data interface
> ----------------------------------------------
>
> Key: ARROW-15656
> URL: https://issues.apache.org/jira/browse/ARROW-15656
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++, R
> Reporter: Jonathan Keane
> Priority: Major
>
> This is currently failing on our valgrind nightly:
> {code}
> ==10301== by 0x49A2184: bcEval (eval.c:7107)
> ==10301== by 0x498DBC8: Rf_eval (eval.c:748)
> ==10301== by 0x4990937: R_execClosure (eval.c:1918)
> ==10301== by 0x49905EA: Rf_applyClosure (eval.c:1844)
> ==10301== Uninitialised value was created by a heap allocation
> ==10301== at 0x483E0F0: memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==10301== by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==10301== by 0xF4756DF: arrow::(anonymous namespace)::SystemAllocator::AllocateAligned(long, unsigned char**) (memory_pool.cc:365)
> ==10301== by 0xF475859: arrow::BaseMemoryPoolImpl<arrow::(anonymous namespace)::SystemAllocator>::Allocate(long, unsigned char**) (memory_pool.cc:557)
> ==10301== by 0xF04192E: GcMemoryPool::Allocate(long, unsigned char**)::{lambda()#1}::operator()() const (memorypool.cpp:28)
> ==10301== by 0xF041EC2: arrow::Status GcMemoryPool::GcAndTryAgain<GcMemoryPool::Allocate(long, unsigned char**)::{lambda()#1}>(GcMemoryPool::Allocate(long, unsigned char**)::{lambda()#1} const&) (memorypool.cpp:46)
> ==10301== by 0xF0419A3: GcMemoryPool::Allocate(long, unsigned char**) (memorypool.cpp:28)
> ==10301== by 0xF479EF7: arrow::PoolBuffer::Reserve(long) (memory_pool.cc:921)
> ==10301== by 0xF479FCD: arrow::PoolBuffer::Resize(long, bool) (memory_pool.cc:945)
> ==10301== by 0xF478A74: ResizePoolBuffer<std::unique_ptr<arrow::Buffer>, std::unique_ptr<arrow::PoolBuffer> > (memory_pool.cc:984)
> ==10301== by 0xF478A74: arrow::AllocateBuffer(long, arrow::MemoryPool*) (memory_pool.cc:992)
> ==10301== by 0xF458BAD: arrow::AllocateBitmap(long, arrow::MemoryPool*) (buffer.cc:174)
> ==10301== by 0xF38CC77: arrow::(anonymous namespace)::ConcatenateBitmaps(std::vector<arrow::(anonymous namespace)::Bitmap, std::allocator<arrow::(anonymous namespace)::Bitmap> > const&, arrow::MemoryPool*, std::shared_ptr<arrow::Buffer>*) (concatenate.cc:81)
> ==10301==
> test-dataset.R:852:3 [success]
> {code}
> https://dev.azure.com/ursacomputing/crossbow/_build/results?buildId=19519&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=d9b15392-e4ce-5e4c-0c8c-b69645229181
> It surfaced with https://github.com/apache/arrow/commit/858470d928e9ce5098da7ebb1926bb3c74dadff0
> Though it could be from: https://github.com/apache/arrow/commit/b868090f0f65a2a66bb9c3d7c0f68c5af1a4dff0 which added some code to make a source node from the C-Data interface.
> However, the first call looks like it might be the line https://github.com/apache/arrow/blob/fa699117091917f0992225aff4e8d4c08910162a/cpp/src/arrow/compute/kernels/vector_selection.cc#L437
--
This message was sent by Atlassian Jira
(v8.20.1#820001)