bad_alloc exception (memory overflow?)

[bluehazzard]

I work on the codeblock code (so quite large project) on Windows and after some time i get a crash with this back trace:

#0 0x9ec4350    __cxa_throw() ([...]\output\share\CodeBlocks\plugins\clanglib.dll:??)
#1 0x9ec41c6    operator new(unsigned int) () ([...]\output\share\CodeBlocks\plugins\clanglib.dll:??)
#2 0x9fa0f58    typeinfo for std::time_put<wchar_t, std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >() ([...]\output\share\CodeBlocks\plugins\clanglib.dll:??)
#3 0x9ec82c0    std::bad_alloc::what() const() ([...]\output\share\CodeBlocks\plugins\clanglib.dll:??)
#4 0x9f5801d    std::allocator_traits<std::allocator<ClAbstractToken> >::max_size(__a=...) ([tdm_gcc_4.9]include/c++/bits/alloc_traits.h:422)
#5 0x9f57ffc    std::allocator_traits<std::allocator<ClAbstractToken> >::allocate(__a=..., __n=262144) ([tdm_gcc_4.9]include/c++/bits/alloc_traits.h:357)
#6 0x9f41a2d    std::_Vector_base<ClAbstractToken, std::allocator<ClAbstractToken> >::_M_allocate(this=0x75119fdc, __n=262144) ([tdm_gcc_4.9]include/c++/bits/stl_vector.h:170)
#7 0x9f67dc6    std::vector<ClAbstractToken, std::allocator<ClAbstractToken> >::_M_emplace_back_aux<ClAbstractToken const&>(this=0x75119fdc) ([tdm_gcc_4.9]include/c++/bits/vector.tcc:412)
#8 0x9f6816e    std::vector<ClAbstractToken, std::allocator<ClAbstractToken> >::push_back(this=0x75119fdc, __x=...) ([tdm_gcc_4.9]include/c++/bits/stl_vector.h:923)
#9 0x9eff36c    ClTreeMap<ClAbstractToken>::Insert(this=0x75119fd8, key="_M_get_Tp_allocator", value=...) ([...]ClangLib/src/treemap.h:38)
#10 0x9ebaf3a   ClTokenDatabase::InsertToken(this=0xa8cfdcc, token=...) ([...]ClangLib\src\tokendatabase.cpp:1070)
#11 0x9ec1b05   ClImportClangToken(cursor=..., scopeCursor=..., typ=ClTokenType_FuncRef, client_data=0xa8cfcc8) ([...]ClangLib\src\translationunit.cpp:997)
#12 0x9ec1ff5   ClAST_Visitor(cursor=..., parent=..., client_data=0xa8cfcc8) ([...]ClangLib\src\translationunit.cpp:1101)
#13 0xf9abd11   libclang!clang_isTranslationUnit() ([...]\output\libclang.dll:??)
#14 0x66    ?? () (??:??)
#15 ??  ?? () (??:??)

The ram usage of codeblocks at this moment is 1.079GByte (normally it is somewhere about 300MB)

in src/treemap.h:32

template<typename _TpVal>
class ClTreeMap
{
public:
    // returns the id of the value inserted
    int Insert(const std::string& key, const _TpVal& value)
    {
        m_Data.push_back(value);
        return m_Tree.Insert(key, m_Data.size() - 1);
    }

the size reported from m_Data.size() is 131072

i have no idea how to debug this error. I have also no idea if this is a memory leak or that the codebase is simply to large (but i don't think that this is the problem, because clang does not throw a badalloc )....

any hint would be appreciated

[yvesdm3000]

Hi,

It's a known problem that the treemap keeps filling up. Deleted entries have its value mostly deleted, but the entry in the vector&map is not removed. This is because of an initial design decision from the original "Alpha" code where each symbol gets an entry in a vector and then keyed in a map. Removing entries in the vector would change all id's that follows the deleted id. I tried to replace it with something more flexible, but then new features popped up that the "new" design didn't cover, so I went along for now with this original design. However I don't think this is the source of the memory leak. It's just an entry in the vector+map that floats around with hardly any data in it and is cleared when the app is restarted.

Maybe some memory-leak tracing tool like valgrind or DrMemory might help ?

Yves

[bluehazzard]

i tried DrMemory, but it crashed, because of internal out of memory xD

I noticed that this crash only happens if my code does not compile. If the code compiles all seems to be ok. Can it be that the plugin does not detect that the parser returned with an error and continued to launch parsers at infinitum?

[yvesdm3000]

I don't think "launching" parsers can be a problem unless maybe they are continuously queued. There are only a couple of threads: The UI thread obviously which also serves as the controlling thread. Then there is a thread to perform code completion and most other operations and a thread with the single purpose to do the background indexing (which might become a threadpool in the future). Since a month or so I introduced another thread that is only used for parsing so that parsing is decoupled from code-completion using 2 instances of a translation-unit. This way the user still has code-completion while a file is re-parsed. If the crash happens when the code doesn't compile, I would rather look at the warning&errors subsystem. I use this plugin on a codebase of a couple of gigabytes worth of sources so the size of the project is probably also not an issue. I do notice memory usage can be pretty large on large files and&or big include trees.