Usually this happens when I inspect a vector (in debug mode and build). Some of its elements appear normally but some others have a text displaying "Failed to execute MI command..." for example. I tried messing around with the settings and searching with google but with no luck.
Any help is much appreciated.
Some info:
g++ --version
g++ (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
gdb --version
GNU gdb (GDB) Fedora 8.3-2.fc30
eclipse version:
Version: 2019-03 (4.11)
java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
Also tested on different hardware with fedora 30, with all updates applied and the same thing happened.
Sample code:
#include <iostream>
#include <vector>
int main() {
std::vector<int> input={1,2,3};
input.resize(2000);
std::cout << "test1" << std::endl;
return 0;
}
Related
I'm using Eclipse 2021-09 (4.21.0) for C++, g++9, gdb9 under Ubuntu 20.04 and I'm sometimes unable to see variables content in Eclipse.
For standard type variables (boolean, int,...) it's OK, but for pointers it fails.
I get the following error:
Multiple error reported.
1) Connection is shut down
2) Unable to create variable object
It looks like that gdb fails because the debugged program stops !?
Here are some details:
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
The gdp process line (using ps): gdb --interpreter mi2 --nx -q --interpreter console -ex new-ui mi /dev/pts/1 -ex set pagination off -ex show version
Any idea? I'm stuck.
I was affected by this too, and spend time tracking down the issue to a gdb bug, which turns out to be known & fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=28711
The problem seems to come from gdb 9.2. Using gdb 8.3 whe have no more problem.
I am using this code as a test.
#include <sstream>
#include <iostream>
int main () {
std::stringstream ss;
ss << "This is a test\n";
std::cout << ss.str();
}
I compile with
g++ -O0 -g test.cpp. When I run the program in gdb and stop at a breakpoint on the cout line, trying to print ss or ss.str() fails.
(gdb) p ss
$1 = <incomplete type>
(gdb) p ss.str()
Couldn't find method std::stringstream::str
gdb also gives me a ton of warnings about the debug information for libstdc++ and libc not matching their respective libraries, followed by an additional warning suggesting I install separate debuginfos.
warning: the debug information found in "/usr/lib/debug/usr/lib64/libc-2.17.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64
However, these packages are already installed according to rpm -qa. I don't have permissions to attempt to reinstall these or try other suggestions from this similar question.
I also found this question and checked the debug-file-directory that gdb is using.
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".
I am running RHEL7 with the included versions of g++ and gdb.
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
The command debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64 will install debugging information for those packages, not the packages themselves.
It seems that a different version of the debugging information has already been installed on the system, so you should be able to request that your system administrator installs matching package versions. (Some companies have policies against installing compilers and debuggers in production, but that does not seem to apply here.)
If you cannot get the correct debuginfo package versions installed on the system, you can download the packages from the Red Hat Customer Portal, copy it to the machine, unpack them using rpm2cpio … | cpio -id, and point GDB to the extracted debugging information. As of this writing, Red Hat does not offer a public symbol server unfortunately.
Note that packages from CentOS will not work even if they have the same name/version/release because they are not binary-identical due to different build environments.
I am trying to Get gdb pretty-print working in eclipse, it seems to be working for all stl elements and containers baring std::string
basically if i have a vector like:
std::vector<std::string> m_vec = {"hello" , "world"};
each element of the vector shows a string and it shows the contents like "hello" and "world".
but if i have a code like
std::string m_string = "hello world";
m_string shows up empty, even though i can do string operations on the contents. Not sure why only strings alone is causing as issue with pretty print.
Any help/pointers would be much appreciated.
Edited:
Few more details regarding the setup:
IDE: Eclipse Luna 4.4.2
Compiler: Cygwin g++ 5.4.0
Debugger: Cygwin gdb 7.10.1
phython : Cygwin phython 3.6
Update: Don't know how exactly, but windows restart solved it, can see string now in preety-print.
For adding support for gdb pretty-printing in cygwin you need the following file available:
/usr/share/gdb/auto-load/usr/bin/cygstdc++-6.dll-gdb.py
It is available in gcc-debuginfo-5.4.0-1 package in cygwin package installer.
Note: This might break once packages get updated in Cygwin repository. So you will need to again locate this file in the Cygwin package search.
Update: Check the version of python interpreter supported by gdb by running the following commands in the gdb console:
(cygwin console) $ gdb
(gdb) python
>import sys
>print(sys.version)
>end
You should see output something like this(in my case it defaults to python2.7 interpreter):
2.7.13 (default, Mar 13 2017, 20:56:15)
[GCC 5.4.0]
TL;DR: A debug toolchain which works perfectly outside of Eclipse terminates automatically when started in Eclipse.
OS: macOS Sierra 10.12.3
IDE: Eclipse IDE for C/C++ Developers, Mars.2, Release 4.5.2
Target Board: WIZwiki-W7500P (via CMSIS-DAP for interactive debugging)
Embedded Platform: mbed-os 5.4
On-chip Debugger: pyOCD 0.8.1a1
Debugger: arm-none-eabi-gdb 7.12.0.20161204-git
Compiler: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205
Following this tutorial, my aim is to use gdb to debug in Eclipse. Via command line,
$ pyocd-gdbserver
successfully starts the server and detects the board, and
$ arm-none-eabi-gdb
successfully starts the debugger and can connect to the server. The program successfully compiles to binary via mbed-cli:
$ mbed compile -t GCC_ARM -m WIZWIKI_W7500P
and flashes to the board, and executes without issue.
In addition, an .elf is generated which can be interactively debugged, breakpoints can be added, and functions can be stepped-through while running on the board.
Finally, the program appears to export successfully to Eclipse:
$ mbed export -t eclipse_gcc_arm WIZWIKI_W7500P --profile mbed-os/tools/profiles/debug.json
including the automatic generation of a Makefile, which successfully orchestrates building in Eclipse.
However, in Eclipse both gdb and pyocd-gdbserver terminate shortly after beginning debug with the following output (despite being configured exactly as they are when I run them in my terminal):
gdb traces:
650,101 2-gdb-show language
650,102 2^done,value="auto"
650,102 (gdb)
650,103 3-data-evaluate-expression "sizeof (void*)"
650,104 3^done,value="4"
650,104 (gdb)
650,104 4-gdb-set language auto
pyocd-gdbserver (n.b. only the last line is different from what's seen in terminal):
WARNING:root:Unsupported board found 2203
INFO:root:DAP SWD MODE initialised
INFO:root:ROM table #0 # 0xe00ff000 cidr=b105100d pidr=4000bb471
INFO:root:[0]<e000e000:SCS-M0+ cidr=b105e00d, pidr=4000bb008, class=14>
INFO:root:[1]<e0001000:DWT-M0+ cidr=b105e00d, pidr=4000bb00a, class=14>
INFO:root:[2]<e0002000:BPU cidr=b105e00d, pidr=4000bb00b, class=14>
INFO:root:CPU core is Cortex-M0
INFO:root:4 hardware breakpoints, 0 literal comparators
INFO:root:2 hardware watchpoints
INFO:root:Telnet: server started on port 4444
INFO:root:GDB server started at port:3333
Started by GNU ARM Eclipse
Outcome:
I've reinstalled each component, begun a fresh workspace and experimented with preferences such as:
How do I prevent this debug system from terminating?
I have the following smal C++ program
#include <stdio.h>
#include <stdlib.h>
int main(void) {
puts("!!!Hello World!!!");
return EXIT_SUCCESS;
}
I compile in Mac OS X Leopard last release using:
g++ -g hello.cpp -o hello.exe
being g++:
host:bin macbook$ g++ --ver
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
then I try to debug this program using fsf-gdb 7.1:
fsf-gdb hello.exe
put a breakpoint in main:
(gdb) b main
Breakpoint 1 at 0x1f8f: file hello.cpp, line 5.
run the program:
(gdb) r
Starting program: /Users/horacio/work/software/gdb/gdb-7.2-inst/bin/hello.exe
Breakpoint 1, main () at hello.cpp:5
5 puts("!!!Hello World!!!");
and try to step, and this happens:
(gdb) n
0x00003045 in ?? ()
This is the output if I do the same under Ubuntu Linux:
(gdb) n
!!!Hello World!!!
6 return EXIT_SUCCESS;
where gdb=7.1 and g++=4.3.4
What is the problem ???? I honestly do not understand why this does not work in mac os x.
Maybe the problem is the gdb version used in mac or the gcc version in mac. Which other alternatives exist for gdb in mac?
Thanks in advance
PS: Apple Leopard's gdb does not produce this error. But I want to use Eclipse CDT, and it can not work with Apple's gdb, that is why I am trying to use a non-Apple gdb version.
This works fine if you use the gdb bundled with Mac. Apple's gcc includes some small Apple-specific extensions, so would not be surprised that it is not 100% compatible with some other version of gdb. You may also have built your custom gdb incorrectly.
You mention that your g++ is 4.3.4, but the one you show above is 4.0.1.
Propably not releted to the actual issue but do remember that when you compile for debugging purposes, disable compiler optimizations with -O0 flag. If you don't pass that for gcc when compiling, you will get "funky" results when you are doing step execution with gdb.
My first thought was that your fsf-gdb doesn't understand Mach-0 binaries.
A quick look at Google came back with: http://reverse.put.as/2009/01/14/how-to-compile-gdb-and-other-apple-open-source-packages-in-mac-os-x/ which reveals that building gdb is not quite as trivial as one might think.