apertium/apertium-separable

Double free in lsx-comp

Closed this issue · 2 comments

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.

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.

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.