Re: [ISSUE] [CLOSED] Qt Creator, std::string (C++) shows as <not accessible> on the debug pane

[voidlinux-github@inbox.vuxu.org]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

Closed issue by Tomab89 on void-packages repository

https://github.com/void-linux/void-packages/issues/14276

Description:
While doing C++ debugging with QtCreator I am unable to view contents of a std::string in the debug pane.
I tried with GCC+GDB and Clang+lldb, with the same result.
gcc-9.1.0_3
gdb-8.3_1
clang-8.0.0_7
lldb-8.0.0_7
I'm not sure if these packages are related to the issue at all. Nor am I certain this is a bug upstream to QtCreator. I searched using Google and it didn't seem that many other users experiences this, at least from the past months.
It could be worth noting that I am using Void Linux at work as well, with QtCreator, GCC and GDB; basically the same environment I use here at home. So, at work, I have none of these issues, and I have not updated that system since August 1st or 2nd.
My system here at home I updated by latest today. However my previous update, about 1-2 weeks ago, I am sure I also received GCC 9.
After the update few weeks back, on my home computer, I launched a debug of one of my pet-projects (no recompiling!) and it ran fine, I could view std::string and do my usual things. I did some source-modifications and re-compiled, and right after that, std::string was not accessible; on all my projects, not even on a simple test-source with a main() and some function calls with a little deeper callstack.

### System
* xuname:  
  Void 4.19.69_1 x86_64 GenuineIntel uptodate rrrrmmnFFFFFF
* package: 
  qtcreator-4.9.2_3

### Expected behavior
std::string is visible in debug pane

### Actual behavior
std::string shows as "not accessible"

### Steps to reproduce the behavior
Create a simple test C++ application using a std::string and try reading its output via a breakpoint. Some times it might show, but in that case, it seems that it might also fail under a little deeper call-stack than just main(). Depth of my call-stack is 5, but is also failing higher up.