How to access map<std::string, int> element using lldb? - c++

Compile the snippet with clang++ -std=c++17 -g source.cpp
#include <map>
#include <string>
int main()
{
std::map<std::string, int> m;
m["foo"] = 23;
}
Try to access the element with key foo, but have errors:
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x000000010000131e a.out`main at source.cpp:8:3
5 {
6 std::map<std::string, int> m;
7 m["foo"] = 23;
-> 8 }
Target 0: (a.out) stopped.
(lldb) p m["foo"]
error: no viable overloaded operator[] for type 'std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >'
candidate function not viable: no known conversion from 'const char [4]' to 'const std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::key_type' (aka 'const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >') for 1st argument
candidate function not viable: no known conversion from 'const char [4]' to 'std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::key_type' (aka 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >') for 1st argument
(lldb) p m[std::string("foo")]
error: no member named 'string' in namespace 'std'
(lldb) p m[std::__1::string("foo")]
error: no matching conversion for functional-style cast from 'const char [4]' to 'std::__1::string' (aka 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >')
candidate constructor not viable: no known conversion from 'const char [4]' to 'const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::allocator_type' (aka 'const std::__1::allocator<char>') for 1st argument
...
candidate constructor not viable: no known conversion from 'const char [4]' to 'std::initializer_list<char>' for 1st argument
candidate constructor not viable: requires 0 arguments, but 1 was provided
...
candidate constructor not viable: requires 4 arguments, but 1 was provided
How to work with string variables in the right way using lldb?

You don't say what versions of clang++ & lldb you are using. Using the tools that ship with Xcode 13, I see:
(lldb) expr m["foo"]
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >::mapped_type) $0 = 23
(lldb) expr m[std::string("foo")]
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >::mapped_type) $1 = 23
which is clearly not what you are getting. These simple seeming C++ expressions actually end up creating a bunch of templated entities behind the scenes, and reconstructing the information needed to instantiate templates from debug information alone is tricky to impossible.
But there has been a bunch of work done recently on the lldb side to support building the clang module for the C++ standard library from which we can extract the necessary information. Either you have an older lldb which doesn't have this work, or for some reason building the clang module is failing. If you are using a current lldb, then you might want to file a bug with http://bugs.llvm.org and see if somebody can help you figure out what's going wrong.
Note, also, lldb doesn't rely on expression evaluation alone for presentation of the common C++ (or ObjC/Swift) containers. It also has a system of "data formatters" which understand the underlying structure of these container classes and can represent the contents w/o having to call the actual language accessors. By default the results of expressions are formatted using the data formatters (expr --raw -- turns the formatters off). That's why you see:
(lldb) expr m
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >) $0 = size=1 {
[0] = (first = "foo", second = 23)
}
rather than all the actual fields of std::map.
In this case, the data formatter for std::map presents the map as a vector of pairs. Since the keys can be anything, this provides a more convenient way to access the elements...
This syntax can't be fed back into the expression evaluator - which is intended to be as close to the source language as possible, but you can use them to dig into local variables using the frame var command - short alias v:
(lldb) v m[0]
(std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int>) [0] = (first = "foo", second = 23)
(lldb) v m[0].first
(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >) m[0].first = "foo"
etc.

Related

Uninitialised value was created by a heap allocation: Unordered_map

SOLUTION: I can have huge strings, then I have to reserve memory for them. Instead of use string I use char pointer in hash table and therefore I reserve the appropriate memory for my hash table keys.
PROBLEM:
I'm sorry if the question already made, but I could not find any answer that helped me.
I've the following code:
EDIT (the main loop of the problematic function for Valgrind)
i = 0;
wordPos = 0;
for (; it != end; ++it,i++){
// I want to ignore this element on purpose
if (i == 1) continue;
bool isscript;
string tag(it->tagName());
convertToLower(tag);
if (it->isTag()==1){
if (tag=="script") isscript = true;
else isscript = false;
}
if (it->isComment()==0 && it->isTag()==0 && isscript==0){
wordlist.clear();
tokenize(it->text(),wordlist);
int ii = 0;
vector<string>::iterator it_palavras = wordlist.begin();
vector<string>::iterator it_words = wordlist.begin();
int ii = 0;
while(ii<wordlist.size()){
string word(wordlist[ii]);
convertToLower(word);
wordsPos++;
if (voc.find(word) == voc.end()){
voc[word] = countwords;
voc_inv[countwords] = words;
term_pos[countwords] = new vector<int>();
term_pos[countwords]->push_back(wordpos);
countwords++;
}else{
if (term_pos.find(voc[word]) == term_pos.end())
term_pos[voc[word]] = new vector<int>();
term_pos[voc[word]]->push_back(wordpos);
}
ii++;
}
}
The type of voc is unordered_map, but when I run valgrind in my code there is the following message:
EDIT Now I'm pasting the complete error with the flag --track-origins=yes.
EDIT 2 Now I'm pasting the complete error with the flag --—dsymutil=yes.
==21036== Use of uninitialised value of size 8
==21036== at 0x4201FF: _platform_memcmp (in /usr/lib/system/libsystem_platform.dylib)
==21036== by 0x10001F10D: std::__1::__hash_iterator<std::__1::__hash_node<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int>, void*>*> std::__1::__hash_table<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int>, std::__1::__unordered_map_hasher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::__unordered_map_equal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::find<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (string:642)
==21036== by 0x10000358F: Colecao::ler_arvore_dom(tree<htmlcxx::HTML::Node, std::__1::allocator<tree_node_<htmlcxx::HTML::Node> > >, int, std::__1::unordered_map<int, std::__1::vector<int, std::__1::allocator<int> >, std::__1::hash<int>, std::__1::equal_to<int>, std::__1::allocator<std::__1::pair<int const, std::__1::vector<int, std::__1::allocator<int> > > > >&) (colecao.cpp:135)
==21036== by 0x100002A19: Colecao::ler(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (colecao.cpp:73)
==21036== by 0x100001781: main (index.cpp:47)
==21036== Uninitialised value was created by a heap allocation
==21036== at 0x70AB: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==21036== by 0x7528D: operator new(unsigned long) (in /usr/lib/libc++.1.dylib)
==21036== by 0x77E12: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long) (in /usr/lib/libc++.1.dylib)
==21036== by 0x10001A0FF: std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, int> > >::__construct_node(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (memory:1505)
==21036== by 0x10000838D: std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, int> > >::operator[](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (unordered_map:1209)
==21036== by 0x100003835: Colecao::ler_arvore_dom(tree<htmlcxx::HTML::Node, std::__1::allocator<tree_node_<htmlcxx::HTML::Node> > >, int, std::__1::unordered_map<int, std::__1::vector<int, std::__1::allocator<int> >, std::__1::hash<int>, std::__1::equal_to<int>, std::__1::allocator<std::__1::pair<int const, std::__1::vector<int, std::__1::allocator<int> > > > >&) (colecao.cpp:139)
==21036== by 0x100002A19: Colecao::ler(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (colecao.cpp:73)
==21036== by 0x100001781: main (index.cpp:47)
When I run the code in a huge amount of data I get segmentation fault, and I think it is because of this Valgrind error.
I don't think I need to reserve space for string in unordered_map, then I figured out that is something in word variable constructor. When I initialize word with a static string (for instance, word("test")), Valgrind stops to complain.
I don't know how to fix this string/unordered_map/memory issue.
EDIT: GDB didn't help me. The segmentation fault is only when I use huge amount of data and then huge amount of memory. The only thing GDB give me is Segmentation Fault and memory address nothing more. Valgrind gave me a more complete message.
This might actually be a problem between Valgrind and the memcmp() implementation of your platform (Mac OS X I suppose?).
The uninitialized value in your application supposedly comes from a malloc() call in std::string constructor, the latter of which is unlikely to "create" uninitialized memory on its own. So my guess would be that malloc() allocates a bit more memory than necessary (aligned to 8 bytes maybe), and _platform_memcmp() also takes these bytes into account. System libraries often have highly-optimized implementations of such functions (memcpy, memcmp, strcpy...). As Valgrind often has trouble with these optimizations, it provides own replacement functions (in mc_replace_strmem.c).
Maybe Valgrind lacks these replacements for OS X memcmp(), or your Valgrind version is too old? Also, there might be a setup problem with your system which prevents Valgrind from detecting the memcmp() function at runtime (I'm not familiar with OS X, but maybe you need some kind of debug info for your system libraries).
So, some questions:
are you running the latest Valgrind version? If not, upgrade it.
what OS X version are you using exactly?
does the problem disappear if you disable optimizations when compiling your application?
If this doesn't help, you might want to ask at the Valgrind users mailing list (http://valgrind.org/support/mailing_lists.html) for this specific problem.
Btw. it's pretty difficult to analyze the Valgrind backtraces without any line numbers. See Debugging Symbols Lost When Linking? for a suggestion to get line number info in the backtraces (in short: add "--dsymutil=yes" to Valgrind command line - but check out the notes for this option in http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts first).

error: invalid initialization of non-const reference of type...from a temporary of type [duplicate]

This question already has answers here:
compiler error saying invalid initialization of reference of type something& from expression of type something*
(3 answers)
Closed 9 years ago.
I thought I could create and populate a C++ map like this:
39 int main(){
40
41 cout << "Approximate travelling salesman path finder." << endl;
42 cout << "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" << endl << endl;
43
44 map<City, OtherCities> database;
45 ReadInData(&database);
46 ...
47 }
As a side note, the ReadInData function just takes a map<City, OtherCities> reference as an argument, where City is just a typedef of string (the name of a city), and OtherCities is a priority queue containing (string, int) pairs that represent other cities and their distances from the first one.
Anyway, attempting to compile this leads to the following error:
pr3.cpp: In function ‘int main()’:
pr3.cpp:45: error: invalid initialization of non-const reference of type ‘std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::priority_queue<OtherCity, std::vector<OtherCity, std::allocator<OtherCity> >, std::greater<OtherCity> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::priority_queue<OtherCity, std::vector<OtherCity, std::allocator<OtherCity> >, std::greater<OtherCity> > > > >&’ from a temporary of type ‘std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::priority_queue<OtherCity, std::vector<OtherCity, std::allocator<OtherCity> >, std::greater<OtherCity> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::priority_queue<OtherCity, std::vector<OtherCity, std::allocator<OtherCity> >, std::greater<OtherCity> > > > >*’
What am I doing wrong here, and (besides using a taboo global variable), is there another nice way to keep the the database in the main function and populate/use it elsewhere? I didn't want to just pass a copy of it by value...
If the function takes a reference, you should pass database, not &database The latter is the address of database, so it's a pointer, not a reference.
Like what you said, ReadInData() is like this:
ReadInData(map<City, OtherCities>& param)
// ^
// NOTICE THIS
It takes param by reference. Thus, you should do:
map<City, OtherCities> database;
ReadInData(database);
// ^
// BYE-BYE &
and not ReadInData(&database); because with that, you are actually passing the address of database to ReadInData(), which is not what ReadInData() needs.

memory corruption due to #pragma pack error - std map corruption- crashing on insert

I have a project I am working on where I have some strange behavior with the std maps.
I had my own typedef map defined which mapped strings to a pointer of a custom type. The application crashed anytime that I excess the map after I add the first pair to the map.
After a lot of messing around I changed the map to a and moved it to the first call in my application and it still crashes. I have no idea what could be going on. Any help would be appreciated.
Here is the code that crashes at the moment.
LoggerPtr syslogger(Logger::getLogger("CISInterface"));
int main(int argc, char *argv[])
{
typedef std::map<string, string> MyMapDef;
MyMapDef tmpString;
tmpString.insert(MyMapDef::value_type("0000", "d"));
tmpString.insert(MyMapDef::value_type("1111", "d")); //Crashes here.
tmpString.insert(MyMapDef::value_type("2222", "d"));
// std::string configFile;
// int c;
// if(argc < 2)
// {
// //Must have c option
// std::cout << "Usage -c configFileName" << std::endl;
// exit(EXIT_FAILURE);
// }
//Rest of main commented out.
...
And here is the stack trace -
CISInterface Debug [C/C++ Application]
gdb/mi (10/31/12 6:02 PM) (Suspended)
Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)
6 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const() 0x00000032fd49c416
5 std::operator< <char, std::char_traits<char>, std::allocator<char> >() basic_string.h:2317 0x0000000000417ec7
4 std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator() stl_function.h:230 0x000000000041706f
3 std::_Rb_tree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, 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>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_insert_unique() stl_tree.h:1170 0x0000000000415d00
2 std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 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>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::insert() stl_map.h:500 0x00000000004150eb
1 main() CISInterface.cpp:29 0x000000000041916d
gdb (10/31/12 6:02 PM)
/home/cillian/workspace/CISInterface/Debug/CISInterface (10/31/12 6:02 PM)
What other areas should I be looking at that could be causing problems. Could it be in the libraries that I'm linking with? I have created a second project with just these lines of code that links with the same libraries (but doesn't have any code that calls into them.) and it doesn't crash.
Problem solved.
Thought I'd add it here on the off chance anyone else ever does the same thing.
I slowly removed files in my project to try and find the offending file. I was thinking that it must be something defined in a header file that was causing issues (like a static). It took a long time but I think I've found it. I had a header file that defines a number of structs. These are serialized to the wire so I had them 1 byte aligned using #pragma pack (push) which I put at the top of the file and #pragma pack (pop) at the bottom. But I then added a couple of #include statements after the first #pragma definition meaning that these includes were aligned incorrectly and caused some nondeterministic behavior. Thanks everyone that had a look. Should probably use the attribute syntax and I wouldn't had the problem. Offending code is below for completeness.
#pragma pack (push)
#pragma pack (1)
#include <string> //Wrong place for includes!
#include <Units.h>
typedef struct
{
....
}
#pragma pack (pop)
Thanks to everyone who had a look at initial problem.

removing strings from a vector via boost::bind

I am trying to remove short strings from a vector.
std::vector<std::string> vec;
// ...
vec.erase(std::remove_if(vec.begin(),
vec.end(),
boost::bind(std::less<size_t>(),
boost::bind(&std::string::length, _1),
5),
vec.end());
The compiler spits out a very large error message:
qwer.cpp:20: error: no matching function for call to 'remove_if(__gnu_cxx::__nor
mal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char
> >*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator
<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::al
locator<char> > > > >, __gnu_cxx::__normal_iterator<std::basic_string<char, std:
:char_traits<char>, std::allocator<char> >*, std::vector<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_strin
g<char, std::char_traits<char>, std::allocator<char> > > > >, boost::_bi::bind_t
<boost::_bi::unspecified, std::less<unsigned int>, boost::_bi::list2<boost::_bi:
:bind_t<unsigned int, boost::_mfi::cmf0<unsigned int, std::basic_string<char, st
d::char_traits<char>, std::allocator<char> > >, boost::_bi::list1<boost::arg<1>
> >, boost::_bi::value<int> > >, __gnu_cxx::__normal_iterator<std::basic_string<
char, std::char_traits<char>, std::allocator<char> >*, std::vector<std::basic_st
ring<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::b
asic_string<char, std::char_traits<char>, std::allocator<char> > > > >)'
The following solution works:
vec.erase(std::remove_if(vec.begin(),
vec.end(),
boost::bind(&std::string::length, _1) < 5),
vec.end());
But I am still curious as to what I did wrong in the first version. Thanks!
It looks like you got your parenthesis off (there should be two after 5, one to close the bind, one to close the remove_if.) I am surprised this didn't give another error message about invalid token or something though, as the parens are clearly unbalanced (did you remove an extra close paren from the end while preparing for SO?). It looks like this is the case, because if you read the template arguments to remove_if in the error message, the next to last one is a boost bind_t, followed by another gnu::iterator.

Seeking STL-aware c++filt

In my development environment, I'm compiling a code base using GNU C++ 3.4.6. Code is under development, and unfortunately crashes now and then. It's nice to be able to run the traceback through a demangler, and I use c++filt 3.4. The problem comes when functions have a number of STL parameters. Consider
My_callback::operator()(
Status&,
std::set<std::string> const&,
std::vector<My_parameter*> const&,
My_attribute_set const&,
std::vector<My_parameter_base*> const&,
std::vector<My_parameter> const&,
std::set<std::string> const&
)
{
// ...
}
When this function is in the traceback, the mangled output on my platform is:
(_ZN30My_callbackclER11StatusRKSt3setISsSt4lessISsESaISsEERKSt6vectorIP13My_parameterSaISB_EERK17My_attribute_setRKS9_IP18My_parameter_baseSaISK_EERKS9_ISA_SaISA_EES8_+0x76a) [0x13ffdaa]
c++filt kindly demangles it to
(My_callback::operator()(Status&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<My_parameter*, std::allocator<My_parameter*> > const&, My_attribute_set const&, std::vector<My_parameter_base*, std::allocator<My_parameter_base*> > const&, std::vector<My_parameter, std::allocator<My_parameter> > const&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x76a) [0x13ffdaa]
This is the same problem as compiler errors encountered when using templates. However, the STL is a fairly regular and recognizable package of templates. So what I'm hoping is that someone out there has created an enhanced version of c++filt which would dump something closer to the original function signature. Any hints?
STLFilt simplifies and/or reformats long-winded C++ error and warning messages, with a focus on STL-related diagnostics. The result renders many of even the most cryptic diagnostics comprehensible.