Printable View
I have a vector of std::string's in an engine console class for one of my games which is used as a log. The console is a singleton so it's cleaned up by the compiler.
The debug CRT reports every logged message as leaked. Is this because the CRT does not see the singleton get 'deleted' since the compiler cleans it up automatically?
It's quite annoying. I can't very well iterate through the vector and call delete on the strings since they are not pointers.
Put breakpoints on the dtor and on the leak report entry point.
My guess is the leak report is called first.
That would be a fair guess: a practical definition of a leak is memory that your program explicitly allocates but does not explicitly deallocate.Quote:
Originally Posted by Bubba
The actual issue is probably the singleton being destructed after the leak is reported.Quote:
Originally Posted by Bubba
I'm guessing your singleton is a static object: it is fairly common for leak detectors to introduce a static object as well (eg its destructor does the reporting). The basic problem is that the order of construction and destruction of static objects is implementation-defined so, without specific help from the compiler, it is impossible to guarantee that the object introduced to support the leak detect is constructed first (ie before your singleton) and destructed last (after your singleton).
A common way to stop such leak detectors from moaning is to avoid reliance on order of construction, which normally means avoiding static objects (at least, ones that directly or indirectly manage resources - which a vector<string> does). That way, you have to write functions that explicitly initialises your singletons and destroy your singletons, and call both explicitly from main(). This ensures your singletons are destructed before main() returns .... and also means they are destroyed before any static objects, such as those involving the leak detector.
I did see a more evil technique once, that involved the singleton intercepting data output by the leak detector, and removing references or reports related to objects managed by the singleton. I mention that in the interests of completeness; I don't offer it as a recommendation.
Every time I try to delete a singleton instance I get major issues. Most of the time it throws.
I'm not sure where the entry point is. I'm not specifically calling for the report other than setting up the CRT so that it auto detects and auto reports.Quote:
Put breakpoints on the dtor and on the leak report entry point.
Just a thought, but if you run a memory leak detector, does it report any leaks?
If it does not, then it probably is a false alarm, and it would be nice to have that confirmed, at the very least.
Without code, it's hard to comment on that, but the #1 cause of problems in a destructor (eg throwing faults when deleting an object) is almost certainly a pointer molestation somewhere else.Quote:
Originally Posted by Bubba
To preach the obvious to the converted .... provide a small but complete sample of code that exhibits your problem .....
That's about all that needs shown. createInstance() is called during setup() which is called from the main process. After that getInstance() is used. Upon shutdown the destructor calls clear on m_Messages. Fairly straightforward, somewhat modified, singleton pattern.Code:class Console
{
public:
static void createInstance();
static Console* getInstance();
...
...
private:
Console();
virtual ~Console();
Console(const Console &obj);
Console& operator = (const Console &obj);
std::list<std::string> m_Messages;
...
...
};
I think I found the problem. Before outputting the messages to the vector log I use ostringstream to create the final string complete with date and time stamp. I think my VS 2005 is pre-SP1 which means there is a definite leak in std::stringstream.
The destruction of the singleton after reporting of memory leaks seems to be a very likely problem (it is pretty common). Did you solve that or rule it out or verify that it is a problem?
It's both and. Stringstream is leaking and the strings are also reported as leaks. It's something I can ignore since the singleton is cleaned up after the mem leak report.
Why?Quote:
Originally Posted by Bubba
Have you confirmed that? I mentioned it as a possible explanation to be chased down.Quote:
Originally Posted by Bubba
Yeah I switched the container to char * and then added a cleanup function and called it before the singleton died. The cleanup iterated the container and cleaned up the memory. This stopped the string leaks.
I thought the string wasn't leaking, it was just getting destroyed after the memory leak detection was run?
If so, then changing to char*'s (especially in a vector) seems like a lot of risk for a non-problem. Is it really that big of a deal that you're getting false leaks reported when you know that they aren't really leaks?
Since every logged message in the console is reported it is sort of a big deal and a major annoyance.
It's not but I cannot clean them up early either. I've tried clear() on the list in a Console::cleanup() function to no avail. So I figured I would force the list into being char * and use std::string.c_str() to place the strings into the list. It seems to have cleaned up the leak reporting.Quote:
I thought the string wasn't leaking, it was just getting destroyed after the memory leak detection was run?
VS2008 complains about private constructors/destructorsQuote:
Originally Posted by Bubba
Ok. So is it saying the compiler cannot clean up the instance b/c it is private?? The whole singleton pattern relies on it. I don't think visibility of the dtor/ctor applies to the compiler cleaning up statics at program exit.