I have not used this extension, this isn’t an answer…maybe it’ll give you a place to start.
Note that std::string is a class and not just the text you see:
http://www.cplusplus.com/reference/string/string/
When you print an “object” in gdb, but you really want some particular field, then you need to specify that…otherwise you might end up seeing a pointer value instead.
For example, you’ll see std::string has a “.data()” and “.c_str()” function. If you string has name “sample”, then in gdb you could:
p sample.data()
p sample.c_str()
The length of the data is found via “.length()”, so you could do this:
p sample.length()
When your code reaches out to a third party library (I’m guessing that’s what your extension does…some kind of binding to python) it is up to the third party library to have debug symbols if you want gdb to see what is going on in that library. I have no idea how gdb behaves with scripted languages such as Python, but I suspect it is just a wrapper library and gdb probably has no way to look inside of Python (there will be other methods, but I have not heard of one for use in gdb). If your string’s “.data()” is a pointer to memory not within your core program, then I’d expect no actual dereferenced value to be available. If the extension is actually part of another class, then I’d expect you to have to drill down further into that class…unfortunately, if that class is part of a library without symbols, then you may not have access to this.
Some code, even if you would normally be able to debug it, may have been optimized such that data placed in registers cannot be seen. Make sure you did not compile with optimization. Make sure your libraries you link against were compiled with debug symbols and that optimization was not used.
For vectors just use member functions to show, e.g.:
# Print third value of zero-based indexing:
p sample_vector[2]
Note that any UNIX style system has a C linker…C was actually invented in conjunction with the invention of UNIX…and Linux follows the POSIX standards which make it “UNIX-like” (UNIX is a trade name, POSIX is the behavior UNIX implements). The linker has no concept of C++ namespaces. This means when there is an overloaded definition a hash value is generated in combination with the obvious name in order to make it unique…one has to “demangle” to reverse this. Some of the random characters you are seeing may be the mangled C name for a namespace-aware signature. Anything linked in by an external C library or C wrapper would have to do this. It wouldn’t matter if there is currently nothing overloaded…the possibility of overloading implies mangling is mandatory before talking to a C-style object which isn’t capable of understanding C++ overloads. I don’t know if this is the case for what you described, but with what you have shown it is a candidate.