Uploaded image for project: 'Apache Arrow'
  1. Apache Arrow
  2. ARROW-2403

[C++] arrow::CpuInfo::model_name_ destructed twice on exit

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 0.10.0
    • C++, Python
    • None

    Description

      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_string<char, std::char_traits<char>, std::allocator<char> >::~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<char, std::char_traits<char>, std::allocator<char> >::~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<char> const&) (basic_string.tcc:1051)
      ==6132== by 0xBEF4F24: std::string::_Rep::_M_clone(std::allocator<char> 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)

      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.

      Attachments

        Activity

          People

            leif Leif Mortenson
            leif Leif Mortenson
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment