It's not useful to see frames such as these on the top of the stack:
```
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (44): UT_DW_USB3.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (146): UT_DW_USB3.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1384): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0x16 bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1178): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (510): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\map (104): UT_DW_USB3.exe!std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>
```
If the leak is really a bug in Microsoft's std::map implementation, for instance, then it's up to Microsoft to fix that. So after reporting the bug I would like to ignore these leaks completely (also from the total # leaks and total bytes leaked at the end of the log).
On the other hand, if the leak is really caused by in user code which happens to use std::map, then I don't care about the details of how std::map is implemented. In that case I would like to filter the frames inside STL code from the log, just to make the log more concise.
So I guess really these are two separate but related requests.
This applies not only to STL but any standard library provided with MSVC (STL, MFC, ATL, etc.). Appropriate paths for these should be pre-configured if possible. It can also apply to a 3rdparty library (e.g. Qt, boost) which is provided by the user: in that case, the user must configure the path(s) for that 3rdparty library.
Comments: Almost always this is problem with deleting class that have std::map data member
```
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (44): UT_DW_USB3.exe!std::_Allocate<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xmemory (146): UT_DW_USB3.exe!std::allocator<std::_Tree_nod<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::b
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1384): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0x16 bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (1178): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\xtree (510): UT_DW_USB3.exe!std::_Tree<std::_Tmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,st + 0xA bytes
e:\ccmaster\sdr\main\windows64\vc90\vc\include\map (104): UT_DW_USB3.exe!std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,CmdHandler::Arg * __ptr64,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>
```
If the leak is really a bug in Microsoft's std::map implementation, for instance, then it's up to Microsoft to fix that. So after reporting the bug I would like to ignore these leaks completely (also from the total # leaks and total bytes leaked at the end of the log).
On the other hand, if the leak is really caused by in user code which happens to use std::map, then I don't care about the details of how std::map is implemented. In that case I would like to filter the frames inside STL code from the log, just to make the log more concise.
So I guess really these are two separate but related requests.
This applies not only to STL but any standard library provided with MSVC (STL, MFC, ATL, etc.). Appropriate paths for these should be pre-configured if possible. It can also apply to a 3rdparty library (e.g. Qt, boost) which is provided by the user: in that case, the user must configure the path(s) for that 3rdparty library.
Comments: Almost always this is problem with deleting class that have std::map data member