[ARROW-15656] [C++] [R] Make valgrind builds slightly quicker

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 8.0.0
• Component/s: C++, R
• Labels: pull-request-available
• External issue URL: https://github.com/apache/arrow/issues/31112
• Assignee: Jonathan Keane
• Reporter: Jonathan Keane
• Created: 10/Feb/22 21:06
• Updated: 11/Jan/23 11:38
• Resolved: 29/Mar/22 23:07

Description

It looks like these specific errors have been resolved in other tickets. In the process of isolating the issue, I found that we actually were building arrow twice in the build. So I've repurposed this PR to remove the extraneous build.

=====

This is currently failing on our valgrind nightly:

==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]

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

Issue Links

• is duplicated by: ARROW-15676 [R] New memory leaks in valgrind nightly build
• links to: GitHub Pull Request #12700