[jira] [Commented] (ARROW-2403) [C++] arrow::CpuInfo::model_name_ destructed twice on exit
[ https://issues.apache.org/jira/browse/ARROW-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429152#comment-16429152 ] Leif Walsh commented on ARROW-2403: --- Ok, my problem was that parquet-cpp was built linking arrow-cpp statically, and then pyarrow was loading both libarrow.so and libparquet.so (which included libarrow.a). Fixed by building with the right cmake option. Thanks, [~xhochy]! > [C++] arrow::CpuInfo::model_name_ destructed twice on exit > -- > > Key: ARROW-2403 > URL: https://issues.apache.org/jira/browse/ARROW-2403 > Project: Apache Arrow > Issue Type: Bug > Components: C++, Python >Reporter: Leif Walsh >Priority: Major > > {noformat} > valgrind --trace-children=yes --track-origins=yes > --keep-stacktraces=alloc-and-free python -c 'import pyarrow' > ... > ==6132== Invalid free() / delete / delete[] / realloc() > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_stringstd::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Address 0x9f1f4b0 is 0 bytes inside a block of size 66 free'd > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_string std::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Block was alloc'd at > ==6132== at 0x4C2901B: operator new(unsigned long) (vg_replace_malloc.c:324) > ==6132== by 0xBEF46CC: allocate (new_allocator.h:104) > ==6132== by 0xBEF46CC: std::string::_Rep::_S_create(unsigned long, unsigned > long, std::allocator const&) (basic_string.tcc:1051) > ==6132== by 0xBEF4F24: std::string::_Rep::_M_clone(std::allocator > const&, unsigned long) (basic_string.tcc:1073) > ==6132== by 0xBEF5359: std::string::assign(std::string const&) > (basic_string.tcc:693) > ==6132== by 0xB18856C: arrow::CpuInfo::Init() (in /path/to/lib/libarrow.so.0) > ==6132== by 0xB190F8D: > arrow::compute::FunctionContext::FunctionContext(arrow::MemoryPool*) (in > /path/to/lib/libarrow.so.0) > ==6132== by 0xAD5EC25: > __pyx_tp_new_7pyarrow_3lib__FunctionContext(_typeobject*, _object*, _object*) > (in /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4F0E122: type_call (typeobject.c:895) > ==6132== by 0xAD5AF0E: __Pyx_PyObject_Call(_object*, _object*, _object*) > [clone .constprop.861] (in > /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0xADEC463: PyInit_lib (in /path/to/lib/pyth > on3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4FA6F17: _PyImport_LoadDynamicModuleWithSpec (importdl.c:159) > ==6132== by 0x4FA4F2A: _imp_create_dynamic_impl (import.c:1982) > ==6132== by 0x4FA4F2A: _imp_create_dynamic (import.c.h:289){noformat} > It appears that the destructor for this static string is being called twice > by {{__run_exit_handlers}} and I don't know why. Anyone else seen this? > For programs which are otherwise normal, this causes (nondeterministic) > aborts on exit when glibc detects the double free. It might be specific to > pyarrow, I haven't tried reproducing it with a C program that links with > libarrow.so yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARROW-2403) [C++] arrow::CpuInfo::model_name_ destructed twice on exit
[ https://issues.apache.org/jira/browse/ARROW-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428436#comment-16428436 ] Leif Walsh commented on ARROW-2403: --- I'll take a look at that, thanks. That's the form of problem I have been assuming it is, but what's weird to me is that it's nondeterministic and seems to happen sometimes to boost::regex symbols, sometimes to arrow symbols (like CpuInfo::model_name_), sometimes to other libraries. > [C++] arrow::CpuInfo::model_name_ destructed twice on exit > -- > > Key: ARROW-2403 > URL: https://issues.apache.org/jira/browse/ARROW-2403 > Project: Apache Arrow > Issue Type: Bug > Components: C++, Python >Reporter: Leif Walsh >Priority: Major > > {noformat} > valgrind --trace-children=yes --track-origins=yes > --keep-stacktraces=alloc-and-free python -c 'import pyarrow' > ... > ==6132== Invalid free() / delete / delete[] / realloc() > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_stringstd::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Address 0x9f1f4b0 is 0 bytes inside a block of size 66 free'd > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_string std::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Block was alloc'd at > ==6132== at 0x4C2901B: operator new(unsigned long) (vg_replace_malloc.c:324) > ==6132== by 0xBEF46CC: allocate (new_allocator.h:104) > ==6132== by 0xBEF46CC: std::string::_Rep::_S_create(unsigned long, unsigned > long, std::allocator const&) (basic_string.tcc:1051) > ==6132== by 0xBEF4F24: std::string::_Rep::_M_clone(std::allocator > const&, unsigned long) (basic_string.tcc:1073) > ==6132== by 0xBEF5359: std::string::assign(std::string const&) > (basic_string.tcc:693) > ==6132== by 0xB18856C: arrow::CpuInfo::Init() (in /path/to/lib/libarrow.so.0) > ==6132== by 0xB190F8D: > arrow::compute::FunctionContext::FunctionContext(arrow::MemoryPool*) (in > /path/to/lib/libarrow.so.0) > ==6132== by 0xAD5EC25: > __pyx_tp_new_7pyarrow_3lib__FunctionContext(_typeobject*, _object*, _object*) > (in /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4F0E122: type_call (typeobject.c:895) > ==6132== by 0xAD5AF0E: __Pyx_PyObject_Call(_object*, _object*, _object*) > [clone .constprop.861] (in > /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0xADEC463: PyInit_lib (in /path/to/lib/pyth > on3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4FA6F17: _PyImport_LoadDynamicModuleWithSpec (importdl.c:159) > ==6132== by 0x4FA4F2A: _imp_create_dynamic_impl (import.c:1982) > ==6132== by 0x4FA4F2A: _imp_create_dynamic (import.c.h:289){noformat} > It appears that the destructor for this static string is being called twice > by {{__run_exit_handlers}} and I don't know why. Anyone else seen this? > For programs which are otherwise normal, this causes (nondeterministic) > aborts on exit when glibc detects the double free. It might be specific to > pyarrow, I haven't tried reproducing it with a C program that links with > libarrow.so yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARROW-2403) [C++] arrow::CpuInfo::model_name_ destructed twice on exit
[ https://issues.apache.org/jira/browse/ARROW-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428384#comment-16428384 ] Uwe L. Korn commented on ARROW-2403: I haven't seen this yet. I had once the problem where other global constants got deallocated twice but that was due to the fact that parquet-cpp was once linked dynamically and once statically in the same process. > [C++] arrow::CpuInfo::model_name_ destructed twice on exit > -- > > Key: ARROW-2403 > URL: https://issues.apache.org/jira/browse/ARROW-2403 > Project: Apache Arrow > Issue Type: Bug > Components: C++, Python >Reporter: Leif Walsh >Priority: Major > > {noformat} > valgrind --trace-children=yes --track-origins=yes > --keep-stacktraces=alloc-and-free python -c 'import pyarrow' > ... > ==6132== Invalid free() / delete / delete[] / realloc() > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_stringstd::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Address 0x9f1f4b0 is 0 bytes inside a block of size 66 free'd > ==6132== at 0x4C28040: operator delete(void*) (vg_replace_malloc.c:507) > ==6132== by 0xBEF47FA: std::basic_string std::allocator >::~basic_string() (basic_string.h:2943) > ==6132== by 0x5E24AA1: __run_exit_handlers (exit.c:78) > ==6132== by 0x5E24AF4: exit (exit.c:100) > ==6132== by 0x5E0CEB3: (below main) (libc-start.c:276) > ==6132== Block was alloc'd at > ==6132== at 0x4C2901B: operator new(unsigned long) (vg_replace_malloc.c:324) > ==6132== by 0xBEF46CC: allocate (new_allocator.h:104) > ==6132== by 0xBEF46CC: std::string::_Rep::_S_create(unsigned long, unsigned > long, std::allocator const&) (basic_string.tcc:1051) > ==6132== by 0xBEF4F24: std::string::_Rep::_M_clone(std::allocator > const&, unsigned long) (basic_string.tcc:1073) > ==6132== by 0xBEF5359: std::string::assign(std::string const&) > (basic_string.tcc:693) > ==6132== by 0xB18856C: arrow::CpuInfo::Init() (in /path/to/lib/libarrow.so.0) > ==6132== by 0xB190F8D: > arrow::compute::FunctionContext::FunctionContext(arrow::MemoryPool*) (in > /path/to/lib/libarrow.so.0) > ==6132== by 0xAD5EC25: > __pyx_tp_new_7pyarrow_3lib__FunctionContext(_typeobject*, _object*, _object*) > (in /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4F0E122: type_call (typeobject.c:895) > ==6132== by 0xAD5AF0E: __Pyx_PyObject_Call(_object*, _object*, _object*) > [clone .constprop.861] (in > /path/to/lib/python3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0xADEC463: PyInit_lib (in /path/to/lib/pyth > on3.6/pyarrow/lib.cpython-36m-x86_64-linux-gnu.so) > ==6132== by 0x4FA6F17: _PyImport_LoadDynamicModuleWithSpec (importdl.c:159) > ==6132== by 0x4FA4F2A: _imp_create_dynamic_impl (import.c:1982) > ==6132== by 0x4FA4F2A: _imp_create_dynamic (import.c.h:289){noformat} > It appears that the destructor for this static string is being called twice > by {{__run_exit_handlers}} and I don't know why. Anyone else seen this? > For programs which are otherwise normal, this causes (nondeterministic) > aborts on exit when glibc detects the double free. It might be specific to > pyarrow, I haven't tried reproducing it with a C program that links with > libarrow.so yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)