"Python Exception <class 'gdb.error'> There is no member named _M_dataplus." when trying to print string - c++

I'm trying to debug a segfault in a homework program and I've discovered that my GDB can no longer even print std::strings. How can I fix it?
I'm on Ubuntu 18.04 LTS.
CLang++ version:
$ clang++ --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
GDB version:
$ gdb --version
GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
I've writen a small test program called gdbbroke.cpp:
#include <string>
int main()
{
std::string test = "sanity check";
return 0;
}
gdbbroke$ clang++ -o gdbbroke gdbbroke.cpp -std=c++11 -Wall -Wextra -Wpedantic -Wconversion -Wnon-virtual-d
tor -ggdb
gdbbroke$ gdb ./gdbbroke
[...]
Reading symbols from ./gdbbroke...done.
(gdb) break main()
Breakpoint 1 at 0x4007a3: file gdbbroke.cpp, line 5.
(gdb) run
Starting program: gdbbroke/gdbbroke
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at gdbbroke.cpp:5
5 std::string test = "sanity check";
(gdb) print test
$1 = Python Exception <class 'gdb.error'> There is no member named _M_dataplus.:
(gdb)
I expected print test to output:
(gdb) print test
$1 = "sanity check"
However it just throws the Python error above.

With Clang, to print the string you need debug symbols of libstdc++ to be installed.
See this Clang bug resolved as INVALID https://bugs.llvm.org/show_bug.cgi?id=24202.
The string should be printed if you install libstdc++ debug symbols. On the other hand you can simply use GCC instead of Clang. In that case you don't need to install libstdc++ debug symbols because GCC already emits them. Clang does not emit them because it does debug information optimization while GCC does not do it. See also related question Cannot view std::string when compiled with clang.

Related

gdb wrong filename in shared library

Trying to learn fmbt ,in the c++ test it is using a shared library, the source file of the shared library is preprocessed from another file as in the following make output shows:
g++ -O0 -g -Wall -pedantic -I../../src -I/usr/include/fmbt -fPIC -c -o mycounter.o mycounter.cc
fmbt-aalc -o mycountertest.cc mycountertest.cc.aal
g++ -O0 -g -Wall -pedantic -I../../src -I/usr/include/fmbt -fPIC -c -o mycountertest.o mycountertest.cc
g++ -shared -o mycountertest.so mycounter.o mycountertest.o
When I am trying to debug the shared the library, it always go to the mycountertest.cc.aal file:
ubuntu#i-hics5mzq:~/fMBT/examples/c++-unittest$ gdb fmbt
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fmbt...done.
(gdb) break awrapper.cc:149
Breakpoint 1 at 0x585e06: file awrapper.cc, line 149.
(gdb) run test.conf
Starting program: /usr/local/bin/fmbt test.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<fmbt_log>
<version>
0.38-1
</version>
<conf_load>
<conf_file name="test.conf"/>
<end_time time="1501727367.947618"/>
</conf_load>
<conf_execute>
<action_name name="iCreate"/>
<action_name name="iDestroy"/>
<action_name name="iIncrement"/>
<action_name name="iReset"/>
<action_name name="iCount"/>
<test_engine>
<tags enabled=""/>
<status steps="0" coverage="0.000000" scov="0.000000e+00"/>
<current_time time="1501727366.958535"/>
<suggested_action type="input" name="iCreate" time="1501727366.958600"/>
Breakpoint 1, Awrapper::execute (this=0x93b6d0, action=std::vector of length 1, capacity 1 = {...}) at awrapper.cc:149
149 int tmp=ada->adapter_execute(1,"");
(gdb) s
_gen_mycountertest::adapter_execute (this=0x94ce50, action=1, param=0x65f8b0 "") at mycountertest.cc.aal:27
27 adapter() {
why gdb is not using the generated mycountertest.cc file.
here is the mycountertest.cc content, does the special class name has something to do with it ? :
#line 3 "mycountertest.cc.aal"
#include "mycounter.h"
#include "aal.hh"
class _gen_mycountertest:public aal {
private:
#line 6 "mycountertest.cc.aal"
//variables
MyCounter* mycounter;
int value;
//action1: "iCreate"
#line 17 "mycountertest.cc.aal"
bool action1_guard(const std::string& name) {
{
return mycounter == NULL;
}
return true;//default
}
why gdb is not using the generated mycountertest.cc file
Because it was told not to. In particular, this line:
#line 17 "mycountertest.cc.aal"
bool action1_guard(const std::string& name) {
tells GCC to tell GDB that whatever code follows was generated from line 17 of mycountertest.cc.aal, so that's what GDB will show.
Usually that's exactly what one wants for generated code.
You can safely strip the #line directives from mycountertest.cc before compiling it, and then GDB will show you the generated source:
fmbt-aalc mycountertest.cc.aal | sed -e '/^#line/d' > mycountertest.cc

objdump -W sees line numbers, objdump -drl and gdb don't? [duplicate]

I am trying to figure out a very strange issue. I have CentOS 6.5 system with gdb:
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
and gcc:
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-8)
I have this file:
#include<stdio.h>
int main()
{
printf("OK!");
return 0;
}
which I compile with:
gcc -o a a.c -g -O0
The file seems to be fine:
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
But when I try to debug it, this happens:
$ gdb a
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from a...done.
(gdb) b main
Breakpoint 1 at 0x4004e4
(gdb) r
Starting program: a
Breakpoint 1, 0x00000000004004e4 in main ()
(gdb) l
1 /* Run time dynamic linker.
2 Copyright (C) 1995-2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
3 This file is part of the GNU C Library.
4
5 The GNU C Library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 The GNU C Library is distributed in the hope that it will be useful,
(gdb) l main
No line number known for main.
I.e., gdb refuses to see any debug information. Anybody has an idea what could be a problem here?
Your GDB is pretty old. Your GCC is fairly new.
I suspect that your GCC is emitting DWARF4 debug info (default as of gcc-4.8 according to release notes), which your GDB does not recognize.
Do you get better result with -gdwarf-2 instead of -g?
If so, upgrade your GDB or use -gdwarf-2 with this compiler.

gdb 7.7 does not step-in on OS-X Mavericks with gcc4.7.3 (Macports)

Here is a simple program:
#include <iostream>
#include <vector>
namespace Example
{
template <int dim>
class Problem
{
public:
void run() {
std::cout<<"here.."<<std::endl;
}
};
}
int main(int argc, char *argv[])
{
Example::Problem<2> problem;
problem.run();
return 0;
}
compiled with Macport's gcc 4.7.3:
g++-mp-4.7 -g -O0 prog.cc -o prog
If I try to debug in gdb 7.7 (self-compiled, not Macport's one!):
$gdb
file prog
b main
r
s
I can't step-in the function:
34 problem.run();
(gdb) s
here..
36 return 0;
(gdb)
Am i doing something wrong? Or does it look like a bug of gdb when used on os-x mavericks?
UPDATE:
I don't see any warning/errors when using gdb:
$ gdb ./prog
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./prog...Reading symbols from /Users/bla-bla-bla/prog.dSYM/Contents/Resources/DWARF/prog...done.
done.
(gdb)
also '-gdwarf-2 -gstrict-dwarf' do not change the behaviour....
UDAPTE2:
I see the same missing call-stack behaviour as here. Although I was not able to check if compiling with -m32 helps in my case, since I have everything for 64bit and thus get undefined symbols problems.
Another stepping problem while debugging is reported here and here on SO.
You need to add -gdwarf-2 option along with -g to debug using gdb for newer version of gcc.
g++-mp-4.7 -g -gdwarf-2 -O0 prog.cc -o prog

Using libc++ causes GDB to segfault on OS X

I'm trying to use C++11 (with Clang and libc++ on OS X) for a program, but whenever I debug with gdb and try to inspect standard containers, gdb segfaults. Here's a minimal example:
file.cpp:
#include <iostream>
#include <string>
int main(int argc, char* argv[])
{
std::string str = "Hello world";
std::cout << str << std::endl; // Breakpoint here
}
If I compile for C++11 using the following:
$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
$
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 -c file.cpp
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 file.o -o program
And then debug as follows, it crashes when I try to p str.size():
$ gdb program
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) br file.cpp:8
Breakpoint 1 at 0x100000d80: file file.cpp, line 8.
(gdb) run
Starting program: /Users/mjbshaw/School/cs6640/2/program
Reading symbols for shared libraries ++............................. done
Breakpoint 1, main (argc=1, argv=0x7fff5fbffab0) at file.cpp:8
8 std::cout << str << std::endl; // Breakpoint here
(gdb) p str.size()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> > (__os=#0x7fff5fc3d628, __str=#0x1) at string:1243
1243
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const) will be abandoned.
If I don't run this in gdb, I get no crash and it works fine (but I need gdb to debug my program). Also, if I remove -std=c++11 -stdlib=libc++ from the compiling options, then it works fine (even in gdb), but I need C++11 for my program.
Are there some known issues with gdb and C++11 (specifically libc++)? I know libc++ and libstdc++ can cause issues if used together, but I'm not trying to use them together (at least not consciously; all I want to use is libc++). Am I specifying some compilation options wrong? Is there a way to properly compile for C++11 on OS X and still be able to debug properly?
GDB 6.3 is almost nine years old. That's just about eternity in Internet years. The product has improved greatly since then. Updating to the last stable release is a must for every developer.

gdb7.6 have no core file handler recognized format

When I used gdb7.6 to analyse the corefile,gdb print the following error:
"./core: no core file handler recognizes format"
My Environment:
HP-UX hp12161 B.11.31 U ia64 0546304299.
Compiler:gcc4.7.2.
gdb7.6 Configure=./configure --enable-64-bit-bfd.
I noticed that in ia64-hpux platform gdb not call set_gdbarch_regset_from_core_section、 deprecated_add_core_fns Interface.
How should I do to solve this problem?
You should use the HPE Wildebeest Debugger. This is HPE's fork of GNU gdb that works on hp-ux. The GNU gdb does not work on hp-ux, neither on executables built with hp-ux aCC nor with those built with gcc.
For example, with whatever version of gdb is available on this system:
[ hp-ux_ia64 ~ ] $ gcc --version
gcc (GCC) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I make a program dump core:
[ hp-ux_ia64 ~ ] $ cat > 1.c
main () { ((int*)0)[0]=1; }
[ hp-ux_ia64 ~ ] $ gcc 1.c
[ hp-ux_ia64 ~ ] $ ./a.out
Segmentation fault (core dumped)
Running GNU gdb on it, I can reproduce the problem you face.
[ hp-ux_ia64 ~ ] $ /usr/local/bin/gdb -c core
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "ia64-hp-hpux11.23".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
"/user/ranga/core": no core file handler recognizes format
(gdb) quit
HPE gdb gives me a proper stack trace.
[ hp-ux_ia64 ~ ] $ /opt/langtools/bin/gdb -c core
HP gdb 6.7 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2011 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.7 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
Reading symbols from a.out...(no debugging symbols found)...done.
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0 0x4000870:0 in main+0x10 ()
(gdb) bt
#0 0x4000870:0 in main+0x10 ()
(gdb)