Hi all,
I run my VC++ 7.1 generated dll under PurifyPlus' control. I get a whole slew of FMM (free memory mismatch) errors for memory chunks allocated by the Microsoft STL. Unfortunately I haven't got the stack trace available right now but I could regenerate it if it's necessary.
One example code snippet looks like this (details omitted):
class ComponentFactoryBox
{
public:
/**
* register Factory in factory box
*/
ComponentFactoryBox* registerFactory(ComponentFactory* factory)
{
m_factories[factory->getName()] = factory;
return this;
}
private:
typedef std::map<BLCString, ComponentFactory*> FactoryMap;
FactoryMap m_factories;
};
The ComponentFactoryBox::registerFactory method gets called to initialise a static pointer. BLCString is just a typedef for std::wstring. The call to registerFactory triggers a call to the destructor of std::pair<std::wstring, ComponentFactory*> which triggers a call to the destructor of std::wstring (well std::basic_string<...> actually) and then somewhere up the stack to std::collate::DoHash, std::0::tan ( ) and then finally 'delete'.
The thing is that Purify insists that the memory was allocated via the corresponding std::pair constructor, std::wstring constructor, std::wstring::assign, ...(some internal wstring stuff), std::collate::DoHash, std::0::tan ( ), std::_Mutex::_Unlock and then 'malloc'.
AFAIK, this is defined as to trigger undefined behaviour (mixing heap and free store (de)allocation functions/operators). Is this a known problem (of either VC++ 7.1 or PurifyPlus) Further I don't know why there has to be memory deallocated anyway when I call std::map's operator[] as there was no such entry set by me; is this some sort of a preallocated entry (as an optimisation) How can I cope with this situation
TIA,
aa

PurifyPlus reports FMM in STL of VC++ 7.1
Raj83475454
Thanks Andreas:
I am unable to locate any new/delete mismatches when I run the code you sent using VS2005.
VC++ 7.1 STL does not have any known issues of this type. Do you have access to VS2005 If so, can you build with it and does it report the same if it runs through Purify Have you contacted Purify They may be aware of this issue.
The Standard C++ Library (and STL) which shipped with VC++ 7.1 is supplied by Dinkumware, Ltd. Their website is http://www.dinkumware.com. This implementation of the STL is so solid that I don't think they have even posted any updates, but you might contact them anyway.
AmA-Nique
Hi Andreas:
We are not aware of any problem like this in the std::basic_string implementation.
Does it change the outcome if you build your app with identical comdat folding suppressed (linker option /opt:noicf), then rerun the Purify test
Best Regards,
Timothy Wilson
I ran the test using a debug build with default settings for /OPT, so /OPT:NOREF and /OPT:NOICF should have been set, if I understand the docs correctly. So actually /OPT:NOICF was in effect in my first test.
cheers,
aa
Cliff Williams
Could you go ahead a regenerate the stack trace you mentioned in your first post.
Also, if there is a small repro you could send or post that would be most helpful.
If you'd like, you can send me files via my email address, which shows in my profile (of course drop the nospam <g>).