[ 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)