Double free in lsx-comp
Closed this issue · 2 comments
bentley commented
Building apertium-fra-cat-1.3.0 fails on OpenBSD due to a double free in lsx-comp. (apertium-3.5.1, lttoolbox-3.4.1, apertium-separable-0.3.0)
lsx-comp lr apertium-fra-cat.fra-cat.l1x fra-cat.autosep.bin
main@standard 28 32
lsx-comp(68548) in free(): chunk is already free 0x100a2b5489c0
gmake: *** [Makefile:770: fra-cat.autosep.bin] Abort trap (core dumped)
gmake: *** Deleting file 'fra-cat.autosep.bin'
This is 100% reproducible on my system. Unfortunately the backtrace isn’t much help since the crash apparently happens at program exit.
TinoDidriksen commented
Can reproduce. Valgrind says:
Invalid free() / delete / delete[] / realloc()
at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5B5C369: __cxa_finalize (cxa_finalize.c:56)
by 0x52CFA92: ??? (in /misc/lttoolbox/lttoolbox/.libs/liblttoolbox3-3.4.so.1.0.0)
by 0x4010DE6: _dl_fini (dl-fini.c:235)
by 0x5B5BFF7: __run_exit_handlers (exit.c:82)
by 0x5B5C044: exit (exit.c:104)
by 0x5B42836: (below main) (libc-start.c:325)
Address 0x8692e30 is 0 bytes inside a block of size 20 free'd
at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5B5BFF7: __run_exit_handlers (exit.c:82)
by 0x5B5C044: exit (exit.c:104)
by 0x5B42836: (below main) (libc-start.c:325)
Block was alloc'd at
at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x56BFA94: void std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_construct<wchar_t const*>(wchar_t const*, wchar_t const*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
by 0x56BFBEB: std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(wchar_t const*, std::allocator<wchar_t> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
by 0x40AB58: __static_initialization_and_destruction_0(int, int) (lsx_compiler.cc:49)
by 0x40B317: _GLOBAL__sub_I__ZN8Compiler24COMPILER_DICTIONARY_ELEMB5cxx11E (lsx_compiler.cc:868)
by 0x410FFC: __libc_csu_init (in /misc/apertium-separable/src/lsx-comp)
by 0x5B427BE: (below main) (libc-start.c:247)
However, there is no cause. No invalid writes, no bad accesses. It just frees the memory wrong, for no particular reason. So I don't currently know how to fix it.
TinoDidriksen commented
Oh wait, lttoolbox is a big hint there. lttoolbox's compiler.h/.cc has the same global static symbols, which I bet messes up the symbol table.