Can you try running your program with ARROW_DEFAULT_MEMORY_POOL=system I am wondering if you are encountering https://issues.apache.org/jira/browse/ARROW-9530
Otherwise, can you run with `--leak-check=full` which should give us a hint where the possibly lost memory is coming from? On Fri, Aug 13, 2021 at 11:52 AM James Van Alstine <[email protected]> wrote: > > Greetings, > > When running a simple C++ hello world program, simply linking against Arrow > produces a valgrind report that looks like the one below. Obviously, there's > some constructors allocating memory before main(). Is this intentional like > the allocators in STL? If it is, is there some way to free whatever is being > allocated? If not, then how do people typically profile their program's > allocations when using Arrow? > > ==1768== Memcheck, a memory error detector > ==1768== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==1768== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==1768== Command: ./hello > ==1768== > Hello World! > ==1768== > ==1768== HEAP SUMMARY: > ==1768== in use at exit: 7,094 bytes in 100 blocks > ==1768== total heap usage: 3,550 allocs, 3,450 frees, 347,875 bytes > allocated > ==1768== > ==1768== LEAK SUMMARY: > ==1768== definitely lost: 0 bytes in 0 blocks > ==1768== indirectly lost: 0 bytes in 0 blocks > ==1768== possibly lost: 368 bytes in 1 blocks > ==1768== still reachable: 6,726 bytes in 99 blocks > ==1768== suppressed: 0 bytes in 0 blocks > ==1768== Rerun with --leak-check=full to see details of leaked memory > ==1768== > ==1768== For lists of detected and suppressed errors, rerun with: -s > ==1768== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
