Vscode-cpptools: Smart pointers cannot be expanded while debugging

[itaiin]

The variables on "locals" and "watch" windows only follow regular pointers, but not with std::unique_ptr<> and std::shared_ptr<>.
While cpptools do recognize them sometimes as structures that can be expanded by showing the arrow symbol next to them, clicking on the symbol does not show the internal structure.

Tested with gdb on linux (ubuntu 16.04)

[pieandcakes]

@itaiin Do you have gdb's pretty printing enabled? This might be a limitation of gdb. You can look at creating a .natvis file to help visualize it.

[itaiin]

@pieandcakes My launch.json config makes gdb run with "-enable-pretty-printing". Maybe indeed this is a gdb issue: I have tried switching to lldb, and it looks like its working.
Now I have another problem where lldb doesn't save me the clutter of the smart pointer internals.

Thanks for pointing to .natvis, out, I did not know about it and will definitely look into it since it seems to solve exactly the problem with lldb.

[s-martin]

So using a dereference *ptr in the Watch window works, but it would be useful, if cpptools did this automatically.

[tndev]

I also have the same problem, I was not able to use .natvis, but patching the SharedPointerPrinter in printer.py is a temporary solution.

[s-martin]

Any news on this issue?

[pieandcakes]

@s-martin Based on the comments, this issue looks like it will require a fix in gdb. Have you tried @tndev 's solution?

[tndev]

@pieandcakes I'm a little conflicted about who is in charge here. On the one hand I would say, that's something the tool like gdb/gcc should provide, because they also have all other pretty printing scrips written. But on the other hand I also think that an IDE also has a "responsibility" to help in such a case.

Anyhow, they probably did some improvements, but I haven't checked them:
Bug 59253 - Python pretty printer should be improved for unique_ptr, shared_ptr and map

[tndev]

It seems that it works with gdb 8.1 and their updated share/gcc-8.1.1/python scripts. It now displays the content of the shared_ptr correctly. I'm not exactly sure if it was really solved by gcc itself or if it is due to other updates of my system.

The only downside that exists right now is that the reference counters are not displayed anymore. Only the the get() child, that enables to do the dereferencing.

[martinakos]

So using a dereference *ptr in the Watch window works, but it would be useful, if cpptools did this automatically.

gdb 8.2
When I do this I get this error: Could not find operator*.
Do I need to enable something else?

[j-bro]

So using a dereference *ptr in the Watch window works, but it would be useful, if cpptools did this automatically.

gdb 8.2
When I do this I get this error: Could not find operator*.
Do I need to enable something else?

I get the same error, any insight?

[BatSvilko]

I have the same problem also with enabled pretty printing. On CLion everything works fine, which means you should fix VS Code.

[dtmoodie]

Same problem, qtcreator has no issues, so this is vs code specific.

[rhan-nreal]

You might try evaluating the *smart_pointer in the DEBUG CONSOLE, such as: if you have a smart pointer smart_ptr, you could run *smart_ptr in the DEBUG CONSOLE, or run smart_ptr->abc to see its member variable abc

[tndev]

@rhan-nreal this will work if you only need to check the contents of a few smart pointers, but if you have a larger structure like a graph/tree, and you want to traverse those nodes, then doing it that way in the console is really time-consuming.

[mattfysh]

I'm gonna try and take a shot at this, as the variables pane is infinitely useful.

Is anyone able to provide a few hints on how the data arrives into that pane? e.g. is it a text-based protocol which consumes the output of a print command?

If yes, where can I find the code that converts the serialized text into the structured data that populates the variables pane?

If no, where should I start looking? I have a feeling it could possibly be an issue with communication between MIEngine and gdb

[mattfysh]

Alright, I think I may have found the issue at least with my setup (Chromium project on Ubuntu). Found that the smart pointer pretty printers do not define a children function

It converts the value at the pointer's address to a string, in it's entirity: https://github.com/chromium/chromium/blob/master/third_party/libcxx-pretty-printers/printers.py#L184-L197

I believe the fix is to implement children, and just found another collection of printers that should work, so will give these a try: https://github.com/llvm/llvm-project/blob/master/libcxx/utils/gdb/libcxx/printers.py

wish me luck!

[tndev]

@mattfysh Yes the fix is to implement children, like in my "patch" in an earlier comment.
The problem is that VSCode comparted to other IDEs that often use their own set of pretty printers, uses only one shipped with the system. So whether you can browse shared ptr or not depends on that.

Up to a certain version of the libstdc++-v3 the children part was missing which results in that problem. But this was changed at some point.

In gcc-9.3.0/libstdc++-v3/python/printer.py the pretty-printer code for shared ptr looks like this:

class SharedPointerPrinter:
    "Print a shared_ptr or weak_ptr"

    def __init__ (self, typename, val):
        self.typename = strip_versioned_namespace(typename)
        self.val = val
        self.pointer = val['_M_ptr']

    def children (self):
        return SmartPtrIterator(self.pointer)

    def to_string (self):
        state = 'empty'
        refcounts = self.val['_M_refcount']['_M_pi']
        if refcounts != 0:
            usecount = refcounts['_M_use_count']
            weakcount = refcounts['_M_weak_count']
            if usecount == 0:
                state = 'expired, weak count %d' % weakcount
            else:
                state = 'use count %d, weak count %d' % (usecount, weakcount - 1)
        return '%s<%s> (%s)' % (self.typename, str(self.val.type.template_argument(0)), state)

And that one should work. If you want to use that code you for sure need to check what function dependencies are in SharedPointerPrinter.

Another solution could be to install a newer version of libstdc++-v3 on the development environment that ships with up to date printer out of the box.

[Spongman]

it would be nice if whatever solution you come up with doesn't require updating gcc. we're currently using vscode-cpptools with centos devtools-7... i wonder if this thread is relevant: https://gcc.gnu.org/legacy-ml/libstdc++/2013-04/msg00133.html

[mattfysh]

I think the solution will depend on your setup, for myself I'm using llvm + libc++, but for @tndev it looks like it may have been an issue with the libstdc++ printers.

If you're using gcc I'm guessing you're using libstdc++ and will benefit from @tndev's solution?

Edit: I'd also point out that this is not an issue with vscode-cpptools, vscode or miengine. it seems to rest further down with gdb+mi (i.e. using mi interface) and python pretty-printers

[tndev]

I initially had the problem, but I'm on a rolling release distribution of Linux (Arch) so I personally don't have that problem anymore @mattfysh.

But I guess the problem still exists on systems like Debian Stable or Ubuntu LTS, as those normally use older more tested versions of the stdlib and the compiler. Or if you need to use an older stdlib for certain development environments like embedded systems.

@Spongman the problem is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59253
The pretty-printer defines how the debugger should map the internal structure of a data type to the structure used by the debugger to show the content correctly or in a more useful way.

The problem technically has to be solved on the side of the stdlib and its pretty printers, because each vendor of a std lib can structure the internals of the classes of the stdlib in the way they think it performs best, that's why libc++ and libstdc++ are not ABI compatible and code based on libc++ and one base on libstdc++ cannot be linked together. The vendors try to make different versions of their own stdlib ABI compatible, but even that is not always the case (e.g. those of Microsoft, but also the on of gcc had at some point ABI incompatibilities). So you cannot use pretty printers of e.g. libc++ for libstdc++.

Due to that an IDE can not create one common pretty printer and use those for every std library. They need to rely on the pretty-printer shipped with the library to be complete/correct. The only thing they could do is to patch the pretty printer for certain versions. In case of larger IDEs like VisualStudio and XCode that ship with the toolchain this is done for the stdlib shipped with that toolchain. But VSCode does not ship with a toolchain, so it is not the case there (and also vscode-cpptools itself does not ship with a toolchain, but uses the one provided by the system).

So to sum it up it is IMHO not a bug of vscode-cpptools, but a feature request to ship with a patch for certain stdlib versions.

[github-actions[bot]]

This issue has been closed automatically because it's labeled as 'external'.