GDB breaks on throw, but not regular exceptions - c++

I am trying to use gdb to debug my c++ program (specifically in VS Code, but this also happens using the command line). I am trying to have gdb break on exceptions so I can have a stack trace, however gdb only breaks on exceptions that I have thrown and not "normal" exceptions.
A minimal reproducible example of this is the following:
example.cpp
#include <vector>
int main() {
std::vector<int> a{};
a.push_back(3);
a.at(2) += 1;
}
Run in command line
g++ example.cpp -o example.exe -g -Wall
gdb example.exe -ex "catch throw" -ex "catch catch" -ex "enable pretty printing" -ex run
GDB outputs
GNU gdb (GDB) 12.1
Copyright (C) 2022 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-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
--Type <RET> for more, q to quit, c to continue without paging--c
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 example.exe...
Catchpoint 1 (throw)
Catchpoint 2 (catch)
0 printers enabled
195 of 195 printers enabled
Starting program: H:\file\path\here\example.exe
[New Thread 11788.0x868]
[New Thread 11788.0x2180]
[New Thread 11788.0x31f4]
30
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 2) >= this->size() (which is 1)
[Thread 11788.0x31f4 exited with code 3]
[Thread 11788.0x2180 exited with code 3]
[Thread 11788.0x868 exited with code 3]
[Inferior 1 (process 11788) exited with code 03]
(gdb)
If I throw std::out_of_range("oops"); in example.cpp however, it does break:
Thread 1 hit Catchpoint 1 (exception thrown), 0x00007ff7dc701598 in __cxa_throw ()
(gdb)
I am on windows, and using msys2, gdb and g++ version 12.1.0.
I've tried break __cxa_throw and many other variations as suggested on other forums, but can't get anything to work.

Related

how to perform input redirection to gdb on cygwin using command-line arguments

This is a follow-up question that originates from the answer from thiefmaster to this question: gdb input redirection using cygwin
I am a beginner, so kindly pardon my ignorance.
I want to know how to redirect input to gdb using a text file while using a command-line argument? if you can elaborate the answer, it would be better. When should I enter command-line argument -f filename. i.e.
i tried following but it didn't work
gcc -g testing3.c -o testing 3.exe
gdb testing3.exe
b main // to ensure it breaks on main
run -f userinput.txt
I have installed cygwin for compiling, running and debugging c
programs. (CYGWIN_NT-10.0-18363 version 3.3.3-341.x86_64)
My userinput.txt is also saved in the same location as the pwd of gdb
I have tried all the following ways, but none seem to work:
attempt#1
gdb ./testing3.exe -i userinput.txt
output of gdb is
Interpretor 'userinput.txt' unrecognized
attempt#2
gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
gdb output is as follows: basically, it still asks for input from STDIN interactively rather than reading from userinput.txt
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb -ex 'set args < userinput.txt' ./exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 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-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 ./exercise5-7.exe...
(gdb) r
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 28036.0x1a48]
[New Thread 28036.0x6cbc]
[New Thread 28036.0x5ab0]
readlines: user input would start shortly
[New Thread 28036.0x4f74]
i am
manually
typing the
input
writelines
i am
manually
typing the
input
[Thread 28036.0x1a48 exited with code 0]
[Thread 28036.0x6cbc exited with code 0]
[Thread 28036.0x6e30 exited with code 0]
[Thread 28036.0x4f74 exited with code 0]
[Inferior 1 (process 28036) exited normally]
(gdb)
attempt#3
gdb ./testing3.exe
b main
r
call dup2(open("userinput.txt",0),0)
gdb outputs
'open' has unknown return type; cast the call to its declared return type
Edit #2: basis comments from matzeri and ssbssa
I tried the suggestion. following is the gdb output:
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ cat userinput.txt
God
is
great
51009396#NHQ-GF-51009396 /cygdrive/d/Let us C/Practice
$ gdb exercise5-7.exe
GNU gdb (GDB) (Cygwin 10.2-1) 10.2
Copyright (C) 2021 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-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 exercise5-7.exe...
(gdb) b main
Breakpoint 1 at 0x100401090: file exercise5-7.c, line 12.
(gdb) delete 1
(gdb) i b
No breakpoints or watchpoints.
(gdb) run < userinput.txt
Starting program: /cygdrive/d/Let us C/Practice/exercise5-7.exe < userinput.txt
[New Thread 22400.0x70d4]
[New Thread 22400.0x70e0]
[New Thread 22400.0x719c]
readlines: user input would start shortly
[New Thread 22400.0x1bec]
God
is still
great
writelines
God
is still
great
[Thread 22400.0x70f0 exited with code 0]
[Thread 22400.0x70e0 exited with code 0]
[Thread 22400.0x70d4 exited with code 0]
[Thread 22400.0x1bec exited with code 0]
[Inferior 1 (process 22400) exited normally]
(gdb)
it basically asks for user input from the STDIN and ignores the userinput.txt file. the messages readlines: use input would start shortly and writelines are my print statements in the code.

schedBreak(<tick>) gdb debugging function not working

I am trying to create breakpoints and debug gem5 using gdb. I referred to http://www.gem5.org/Debugger_Based_Debugging.
As in the official documentation in the above link, I tried `call schedBreak() but it doesn't work. the following are the full commands:
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 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"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreak(10000)
warn: need to stop all queues
(gdb) c
Continuing.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Aug 26 2019 20:59:02
gem5 started Sep 8 2019 15:17:55
gem5 executing on nirmal-cadsl2, pid 30158
command line: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 501393000 because exiting with last active thread context
[Inferior 1 (process 30158) exited normally]
(gdb)
While this other tutorial http://gem5.org/wiki/images/0/0e/ASPLOS2017_gem5_tutorial.pdf (assuming the debug function is not particular to ISA) tells me that the function is actually schedBreakCycle(), it gives me this No symbol "schedBreakCycle" in current context. The full commands shown below.
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 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"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreakCycle(10000)
No symbol "schedBreakCycle" in current context.
(gdb)
gem5 version: ea8c435b6c6c092d72047eee50f125f5ae7347c3
gdb version: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Also, if I want to debug ALPHA or ARM full system on my ubuntu 18.04(x86), do I have to use any cross-compiled gdb versions or would native gdb suffice?
The tutorial is correct, you have to pass --debug-break to gem5:
gdb --args gem5.debug --debug-break=1000 ...
and then without breaking at main:
run
call schedBreak(5000)
continue
--debug-break generates a break at time 1000 and makes GDB stop there after main, and from that point, schedBreak does work.
Or alternatively first go to:
tbreak doSimLoop
run
call schedBreak(5000)
continue
schedBreak schedules an event in the event queue, which cannot be ready at main.
The breaks work by raising a signal, which GDB stops at by default.
ALPHA and ARM won't make a difference since schedBreak is a tiny helper to debug the host emulator itself, which is likely an x86 program. To debug the guest code, which is what most people want, see e.g. this tutorial.
Tested gem5 master at e87a293d1ffa6da38ba8fa145e7dc5128138ab77 in an X86 debug build.

gdb in emacs hangs when issuing the 'q(uit)' command

I'm using emacs 24.5.1 under Mac Yosemite, in graphical mode and I'm trying to get gdb 7.11 working.
After starting gdb with 'gdb', I use 'r' to run a mini C++ code, consisting only of an empty main(), which exits normally. After it exits I can type 'r' again and the program will run and exit fine again. However, when I type 'q' to quit gdb, I get a newline without the (gdb) prompt, but gdb does not seem to have quit; It no longer responds to input, but when I try invoking gdb again, emacs tells me that 'this program is already being debugged'.
Current directory is ~/cpp/ppcpp/
GNU gdb (GDB) 7.11
Copyright (C) 2016 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-darwin15.4.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 a.out...Reading symbols from /Users/mwisse/cpp/ppcpp/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) r
Starting program: /Users/mwisse/cpp/ppcpp/a.out
[Inferior 1 (process 98675) exited normally]
(gdb) r
Starting program: /Users/mwisse/cpp/ppcpp/a.out
[Inferior 1 (process 98677) exited normally]
(gdb) q
...This is me typing something to show I can type anything here...
but no response.
Has anyone seen this before?
I didn't find out what caused the issue, but it went away after replacing my .emacs.d directory with the one mentioned here: http://tuhdo.github.io/emacs-for-proglang.html.

Compiling a Qt application in order to get better debuginfos (Linux)

I downloaded FabariaGest source code then to compile it you have to run:
on qt 4 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT4=ON -DWANT_QWT=ON
on qt5 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT5=ON -DWANT_QWTQT5=ON
When it finishes, you run
# make install
Since I get a segmentation fault when I start the software, I tried to run
cd /opt/fabaria_gest
gdb fabaria_gest
run
backtrace
but I only get
[user#localhost fabaria_gest]$ gdb fabaria_gest
GNU gdb (GDB) Fedora 7.9.1-19.fc22
Copyright (C) 2015 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".
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 fabaria_gest...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/fabaria_gest/fabaria_gest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 7246.
[New Thread 0x7fffe0798700 (LWP 7244)]
Program received signal SIGSEGV, Segmentation fault.
0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
(gdb) backtrace
#0 0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
#1 0x0000000000502a92 in QtPrivate::RefCount::ref() ()
#2 0x0000000000502e37 in QString::QString(QString const&) ()
#3 0x00000000006b9709 in _ZL13getSystemInfov ()
#4 0x00000000006bc29f in main ()
(gdb)
#0 0x00
What can I do to recompile the software in order to get better debuginfos? Setting set follow-fork-mode in GDB did not help
Using
cmake -DCMAKE_BUILD_TYPE=Debug ...
will instruct cmake to generate debug information, which should make the backtrace easier to read.

Debugging MinGW program with gdb on Windows, not terminating at assert failure

How do I set up gdb on window so that it does not allow a program with assertion failure to terminate? I intend to check the stack trace and variables in the program.
For example, running this test.cpp program compiled with MinGW 'g++ -g test.cpp -o test' in gdb:
#include <cassert>
int main(int argc, char ** argv) { assert(1==2); return 0; }
Gives:
$ gdb test.exe
GNU gdb 6.8
Copyright (C) 2008 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 "i686-pc-mingw32"...
(gdb) r
Starting program: f:\code/test.exe
[New thread 4616.0x1200]
Error: dll starting at 0x77030000 not found.
Error: dll starting at 0x75f80000 not found.
Error: dll starting at 0x77030000 not found.
Error: dll starting at 0x76f30000 not found.
Assertion failed: 1==2, file test.cpp, line 2
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Program exited with code 03.
(gdb)
I would like to be able to stop the program from terminating immediately, like how Visual Studio's debugger and gdb on Linux does it. I have done a search and found some stuff on trapping signals but I can't seem to find a good post on how to set up gdb to do this.
Found out that the breakpoint can be put in the .gdbinit file with the lines:
set breakpoint pending on
b exit
This removes the need to enter yes for windows.
Just set a breakpoint on exit:
(gdb) b exit
Using recent (March 2017) msys2 with gcc 6.3 and gdb 7.12.1 you should use:
break _exit
i.e. use _exit and not exit. I expect this also to work in other cases as I expect that exit will call _exit to actually exit.