Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

HUGE MEMORY LEAK pinpointed!

<< < (11/21) > >>

Der Meister:
Again bad news: I spotted only one location with a call to FileManager::Load without freeing the reserved memory:
- src/app.cpp:512

But adding this delete did not solve our big memory lead. Perhaps a small one, but not our real one. I have no idea where there is a call to delete missing. *Maybe* somewhere in the CC-plugin but I didn't find it. Anyway, if I did not overlook something the CC-plugin delegates the ownership of this objects to the cbThreadPool. I did not understand this class completely but it has calls to delete but I'm not sure if they are really used. There is at least one in the destructor of the thread pool which should free all memory but this one would not solve our problem as it would only free the memory when Code::Blocks is closed. But we have to free the memory after the CC-plugin finished its parsing.


Edit: Found two minor possible memory leaks. Shouldn't there be deletes in the following two functions?

--- Code: ---bool Parser::ParseBufferForFunctions(const wxString& buffer)
{
    ParserThreadOptions opts;
    opts.wantPreprocessor = m_Options.wantPreprocessor;
    opts.useBuffer = true;
    opts.bufferSkipBlocks = true;
    opts.handleFunctions = true;
    ParserThread* thread = new ParserThread(this,
                                            buffer,
                                            false,
                                            opts,
                                            m_pTempTokens);
    return thread->Parse();
}

bool Parser::ParseBufferForUsingNamespace(const wxString& buffer, wxArrayString& result)
{
    ParserThreadOptions opts;
//    opts.wantPreprocessor = m_Options.wantPreprocessor; // ignored
//    opts.useBuffer = false; // ignored
//    opts.bufferSkipBlocks = false; // ignored
    ParserThread* thread = new ParserThread(this,
                                            wxEmptyString,
                                            false,
                                            opts,
                                            m_pTempTokens);
    return thread->ParseBufferForUsingNamespace(buffer, result);
}

--- End code ---

rickg22:
Yes, you're right about that one. Still small, but better than nothing.

However I still have the impression that those memory leaks must be found elsewhere. This is quite a sleuth case...  :?

Der Meister:
Yes, they really should be found and fixed. But digging throw the CC-plugin isn't really easy and I didn't find a problem yet.

dmoore:
i ran some quick constructor/destructor counting tests and confirmed file loaders weren't being released as per valgrind logs. with CC enabled, this lead to thousands of open file loaders being left behind after opening and closing the CB main project a couple of times. I think similar problems could plague other plugins if they use the loader (filemanager seems to require callers to release loaders, but only after they have finished loading??)

hacky patch here: http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2075&group_id=5358

please test. I think the problem boils down to the parser code only releasing file loaders if the thread is actually parsed (not all files will get the ok for parsing). i changed the code to only start a file loader if parsing is actually required. the affected functions are onparsefile and batchparse and bool Parser::Parse(const wxString& bufferOrFilename, bool isLocal, ParserThreadOptions& opts)

PS: the cc code is spaghetti with (IMHO) an unnecessarily complex threading model.

Der Meister:
Thank you for the patch, it seems to work quite well. Just compiled Code::Blocks with it and did a short test within valgrind. I didn't look through the whole output but the big leak from the FileLoader seems to be gone.  8)

Navigation

[0] Message Index

[#] Next page

[*] Previous page