[Bug python/16436] pointed-to objects are not pretty printed

https://sourceware.org/bugzilla/show_bug.cgi?id=16436

Stepan Gatilov <stgatilov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stgatilov at gmail dot com

--- Comment #5 from Stepan Gatilov <stgatilov at gmail dot com> ---
I can't see how this is "not a bug" or "Eclipse specific".

Here is what I get now for std::string in GDB console of VS Code:

-exec print str
$1 = "Hello"
-exec print pstr
$2 = (std::string *) 0x7fffffffd0a0
-exec print *pstr
$3 = "Hello"

As a typical user (especially coming from Visual C++), I expect to see this:

-exec print str
$1 = "Hello"
-exec print pstr
$2 = 0x7fffffffd0a0 "Hello"
-exec print *pstr
$3 = "Hello"

These text printouts don't even remotely show how bad the situation is for MI
users, i.e. IDEs. Because if I add `pstr` to watch and expand it, I see
`_M_dataplus`, `_M_string_length`, `<anonymous union>` inside.

And people who try to implement custom pretty printers bump into this issue
regularly. For instance, consider these questions:
*
https://stackoverflow.com/questions/71906297/full-gdb-pretty-printer-class-syntax-for-simple-c-class-example
*
https://stackoverflow.com/questions/16480045/print-the-whole-linked-list-in-gdb
*
https://stackoverflow.com/questions/53602037/how-can-i-pass-the-data-type-in-a-generic-linked-list-to-the-gdb-print-command

The first possible solution on the user side is to implement a pretty printer
for pointer type, then selectively apply it for his own customized types. This
does not cover STL types unfortunately. And we have problems even here:
1. `RegexpCollectionPrettyPrinter` can't be made to match pointers. At least I
failed to achieve that.
2. `pretty_printers.append` can match pointer types, but it has its caveats.
Like not resolving typedefs, having to not to forget to include pointers of
various constness. Well, at least references are handled properly.

The second possible solution is to implement a generic system that matches
pointers automatically. This means implementing a custom
`printing.PrettyPrinter`. This is not easy to do and requires time investment:
there are many tricky details which are hard to get right from the first go.
Here is an example of what I'm talking about:
*
https://dirtyhandscoding.github.io/posts/natvis-like-experience-with-gdb-pretty-printers-implementing-natvis-features.html#printer-behind-pointer

And after doing this, we suddenly discover that GDB is incapable of dealing
with cyclic child dependencies! I mean, it is very typical to have many loops
in the structure of pointers. But GDB builtin deep printing algorithm is not
protected against it, it simply hangs! It is described here:
*
https://dirtyhandscoding.github.io/posts/natvis-like-experience-with-gdb-pretty-printers-introduction.html#inspection-model

One might argue that this is users' fault, they can simply avoid deep printing
by limiting depth to zero or something like that. But unfortunately, many MI
commands include an innocent-looking mode "simple values", which triggers deep
printing of pointers. Out of 4 IDEs using MI, only one does not fall into that
trap. You can read more about IDE issue here:
*
https://dirtyhandscoding.github.io/posts/natvis-like-experience-with-gdb-pretty-printers-debugging-and-ides.html#debuggers-hang

Here are direct links to the debugger bug reports:
* https://github.com/microsoft/vscode-cpptools/issues/14487
* https://bugs.kde.org/show_bug.cgi?id=522317
* https://github.com/cs01/gdbgui/issues/514
Maybe deprecate this "simple values" option and add a note into the docs why it
is dangerous?

Finally, this hanging issue is totally avoidable with a better deep-printing
algorithm. I believe MSVC has one and runs it automatically for all the values
in the Watch on every debugger pause.
*
https://dirtyhandscoding.github.io/posts/natvis-like-experience-with-gdb-pretty-printers-auto-summary.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.