Is there a libarrow deb with debug symbols so I can resolve the (???)s valgrind returns?
On Fri, Aug 13, 2021 at 5:34 PM James Van Alstine <[email protected]> wrote: > Yes, > > For you can repro: > > Program: > ``` > #include <iostream> > > int main() { > std::cout << "Hello World!" << std::endl; > > return 0; > } > ``` > Executable: > ``` > clang++-10 -g -Wall -O2 -l:libarrow.so main.cc -o hello > ``` > > with --leak-check=full > ``` > ind --leak-check=full ./hello > ==6456== Memcheck, a memory error detector > ==6456== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==6456== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==6456== Command: ./hello > ==6456== > Hello World! > ==6456== > ==6456== HEAP SUMMARY: > ==6456== in use at exit: 7,094 bytes in 100 blocks > ==6456== total heap usage: 3,550 allocs, 3,450 frees, 347,875 bytes > allocated > ==6456== > ==6456== 368 bytes in 1 blocks are possibly lost in loss record 12 of 15 > ==6456== at 0x483DD99: calloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==6456== by 0x40149CA: allocate_dtv (dl-tls.c:286) > ==6456== by 0x40149CA: _dl_allocate_tls (dl-tls.c:532) > ==6456== by 0x6A1D322: allocate_stack (allocatestack.c:622) > ==6456== by 0x6A1D322: pthread_create@@GLIBC_2.2.5 > (pthread_create.c:660) > ==6456== by 0x58E5AB5: ??? (in > /usr/lib/x86_64-linux-gnu/libarrow.so.500.0.0) > ==6456== by 0x58E6B62: ??? (in > /usr/lib/x86_64-linux-gnu/libarrow.so.500.0.0) > ==6456== by 0x58E6CEB: ??? (in > /usr/lib/x86_64-linux-gnu/libarrow.so.500.0.0) > ==6456== by 0x4011B89: call_init.part.0 (dl-init.c:72) > ==6456== by 0x4011C90: call_init (dl-init.c:30) > ==6456== by 0x4011C90: _dl_init (dl-init.c:119) > ==6456== by 0x4001139: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so) > ==6456== > ==6456== LEAK SUMMARY: > ==6456== definitely lost: 0 bytes in 0 blocks > ==6456== indirectly lost: 0 bytes in 0 blocks > ==6456== possibly lost: 368 bytes in 1 blocks > ==6456== still reachable: 6,726 bytes in 99 blocks > ==6456== suppressed: 0 bytes in 0 blocks > ==6456== Reachable blocks (those to which a pointer was found) are not > shown. > ==6456== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==6456== > ==6456== For lists of detected and suppressed errors, rerun with: -s > ==6456== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > ``` > > If by `ARROW_DEFAULT_MEMORY_POOL=system` you mean setting that as an env > var and then running the same executable, then > the valgrind output is the same. > > I think what is happening here is glibc is running _dl_init() when > linking, which is kicking off the constructor of some global object in > Arrow. > > > On Fri, Aug 13, 2021 at 5:20 PM Weston Pace <[email protected]> wrote: > >> 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) >> >
