I'm getting an an annoying error every time gdb catches an exception.
I've run the following example program
#include <stdexcept>
int main() {
throw std::invalid_argument("");
return 0;
}
And the result from running gdb is
terminate called after throwing an instance of 'std::invalid_argument'
what():
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
It's not all that bad, as I do get the information I need, it's just bugging me...
Do anyone know how to fix this?
To do full source code debugging of the C library on Ubuntu, there are just a few steps to take:
Install the debuginfo version of libc6.
It's probably already installed - the gdb package on Ubuntu has a dependency on it - but in case it isn't, run sudo apt install libc6-dbg.
Prepare the package system to download and process source code packages, if this hasn't previously been done.
sudo apt install dpkg-dev
grep deb-src /etc/apt/sources.list
Grep's output should show (and there may be additional matches that we don't need to worry about):
deb-src http://archive.ubuntu.com/ubuntu/ bionic main restricted
deb-src http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted
If the grep shows that these deb-src lines are commented out with #:
# deb-src http://archive.ubuntu.com/ubuntu/ bionic main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted
then edit /etc/apt/sources.list to remove the # at the beginning of these lines and then run sudo apt update .
Download the source code corresponding to the installed version of the C library.
First, create a directory anywhere - I'll use /opt/src here.
Then do the following:
cd /opt/src
apt source libc6
If the apt command gives an error message like
E: You must put some 'source' URIs in your sources.list
then my instructions in step 2 may have become outdated; post a comment here.
When the download is complete, run this:
find $PWD -maxdepth 1 -type d -name 'glibc*'
Remember this name - it'll be something like /opt/src/glibc-2.23
Determine where gdb expects to find the source code and make appropriate adjustments.
Run gdb, have it run your program until it stops, and at the gdb prompt do this:
(gdb) info source
Current source file is ../sysdeps/unix/sysv/linux/raise.c
Compilation directory is /build/glibc-KM3i_a/glibc-2.23/signal
So gdb is expecting the source code to be in /build/glibc-KM3i_a/glibc-2.23 . There are two ways to fix this:
Move (or use a symlink) so that the source code is (or appears to be) in /build/glibc-KM3i_a/glibc-2.23 .
or
Tell gdb how to substitute the correct source directory pathname:
(gdb) set substitute-path /build/glibc-KM3i_a/glibc-2.23 /opt/src/glibc-2.23
Now, go back to your frame, and gdb should show the source code line:
(gdb) frame 1
#1 0xb7e2fea9 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Related
I am debugging a coredump file from the production environment(two environment, not the same), I input "gdb [programe name] core.xxx then bt" but it hint like the title and pic below:
enter image description here
There are question masks at the top of the stack and I can't find where the Segmentation fault generated
Kernel Version: enter image description here
Linux Version: enter image description here
System compiled from executable file:enter image description here
(Note :Source code and executable program are not in the same system)
I want to find a way to know where did the segment error occur, I'd appreciate it if you could help me !
I have installed some missing rpm libraries according to the prompts but still not work:
glibc-debuginfo-2.17-326.el7_9.x86_64.rpm
libgcc-4.8.5-44.el7.i686.rpm
ncurses-libs-5.9-14.20130511.el7_4.i686.rpm
libstdc++-4.8.5-44.el7.i686.rpm
kernel-debug-debuginfo-3.10.0-1160.el7.x86_64.rpm
kernel-debuginfo-common-x86_64-3.10.0-1160.el7.x86_64.rpm
My OS CentOS 7.9
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64 libconfig-1.4.9-5.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64
You need to modify the enable=1 of the "/etc/yum.repos.d/CentOS-Debuginfo.repo" file first
Use sudo yum install glibc to install
yum install yum-utils
Use debuginfo-install glibc-2.17-326.el7_9.x86_64 to install.
Hope this help.
I tried to build a gdb for esp32 that works with qemu, but after many attempt, I didn't manage. All my attempts leaded me to the following error message after connecting to the remote target: Remote 'g' packet reply is too long.
Right now I am using the prebuilt version from Ebiroll: https://github.com/Ebiroll/qemu_esp32/blob/master/bin/xtensa-esp32-elf-gdb
but I would like to use a newer gdb version than 7.10, did anyone had success with this?
Here is how I built gdb:
git clone --depth 1 --branch esp-2021r2-gdb https://github.com/espressif/binutils-gdb.git
cd binutils-gdb
mkdir -p build
cd build
../configure --without-guile --host=x86_64-pc-linux-gnu --target=xtensa-esp32-elf --disable-werror
make
make install
(note from this branch the patch to apply from the Zephyr project, as described here https://github.com/Ebiroll/qemu_esp32#qemu-esp32, seems to already be included)
I also tried by applying the following patch (no success):
curl -L https://raw.githubusercontent.com/Ebiroll/gdb/master/gdb/xtensa-config.c.qemu --output binutils-gdb/gdb/xtensa-config.c
or patching qemu to fix the value of num_regs (tried 104 and 172, also no success).
Espressif's qemu wiki mentions setting an environment variable to only list the core registers:
export QEMU_XTENSA_CORE_REGS_ONLY=1
This needs to be set in the environment from where qemu will be executed.
My recommendation is to use both qemu and gdb (from the Esp32 tool chain) as provided by Espressif. I have recently used this combination with success. The latest release uses gdb 9.2.
How can I include/view the source code of malloc in gdb?
I want to do a step by step execution in gdb, and step into malloc.c source code when any of the malloc functions is called.
Currently what gdb says is:
malloc.c: No such file or directory.
This guy here faced the same problem, but they do not mention a solution, ie how to actually step into the source code of malloc.
I am on Ubuntu server 14.04, and I have already tried to install the following:
libc6-dbg, libc6-dev, and libc6-dbgsym.
I don't even know if one of these packages might help, but installing the libc-dbgsym gives me the following error:
dpkg: error processing archive /var/cache/apt/archives/libc6-dbgsym_2.19-0ubuntu6.6_amd64.ddeb (--unpack): trying to overwrite
'/usr/lib/debug/usr/lib/x86_64-linux-gnu/audit/sotruss-lib.so', which
is also in package libc6-dbg:amd64 2.19-0ubuntu6.6 dpkg-deb: error:
subprocess paste was killed by signal (Broken pipe)
The following worked for me. Not sure whether there is a better way.
Install libc6-dbg (which you have already done):
sudo apt-get install libc6-dbg
Install the eglibc-source package (ubuntu actually uses eglibc): sudo apt-get install eglibc-source.
Unpack the tar file that was installed in /usr/src/glibc: /usr/src/glibc $ sudo tar xvf eglibc-2.19.tar.xz
Crank up gdb and add in the path to the malloc source: (gdb) dir /usr/src/glibc/eglibc-2.19/malloc
(gdb) n
13 char *c = malloc(100);
(gdb) s
__GI___libc_malloc (bytes=100) at malloc.c:2876 2876
{
(gdb)
Gdb can only show the source codes because the debug-compiled binaries contain references between the binary code and the source files.
malloc() is in the C library. On normal systems, it is not compiled with debug metadata, and its sources are also not installed in the system.
But they are reachable, you only need to install the debug versions of these libraries. For example, on debian an apt-get install glibc-debug or similar will do it. On SuSE, a zipper in libc6-debug (afaik, maybe the exact package names could be a little bit differ).
I compiled a simple go application with debug flags:
go build -gcflags "-N -l" -o main main.go
main.go
package main
import (
"fmt"
"time"
)
func main() {
for i := 0; true; i++ {
fmt.Println("number:", i)
time.Sleep(time.Second)
}
}
In gdb, I attached to its pid and executed break and break 11.
gdb --pid=<pid>
Gdb reports that the breakpoints are successfully set, but they don't ever get hit. Is there a way to get this working?
Note: that same setup (even when adding your runtime-gdb.py to your .gdbrc) risks to not work with Ubuntu 13.10, where you would get a "SyntaxError" message, as illustrated in:
blog post "Debugging Go 1.2 on Ubuntu 13.10 with GDB" from Michael Susens-Schurter (schmichael)
issue 6698 (gdb: upgrade to be python 3 compatible)
The problem is that Ubuntu 13.10 links GDB against Python 3.3 while the script golang ships is for Python 2. Someone has already filed an issue, and it appears to be fixed upstream (so expect Go 1.3 to Just Work).
Luckily backporting the fix is easy. Simply move your exist runtime-gdb.py out of the way and download the upstream version in its place.
If your $GOROOT is /usr/local/go the following should Just Work:
sudo mv /usr/local/go/src/pkg/runtime/runtime-gdb.py /usr/local/go/src/pkg/runtime/runtime-gdb.py.orig
cd /usr/local/go/src/pkg/runtime/
sudo wget https://go.googlecode.com/hg/src/pkg/runtime/runtime-gdb.py
the go/src/pkg/runtime/runtime-gdb.py script needs to be loaded inside gdb to effectively be able to debug go programs.
You can add it to the .gdbrc file.
CentOS 6.2 + GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6)
When I debug a simple c++ code with GDB, I saw the following warning:
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6_2.9.i686 libgcc-4.4.6-3.el6.i686 libstdc++-4.4.6-3.el6.i686
I have tried the following methods and none of them fix the problems:
Search SO
yum install glibc
debuginfo-install glibc-2.12-1.47.el6_2.9.i686 libgcc-4.4.6-3.el6.i686 libstdc++-4.4.6-3.el6.i686
In fact, when I install those RPM one by one, I just realized that they are installed already.
[root#localhost Excluded]# rpm -ivh glibc-2.12-1.47.el6_2.9.i686.rpm
Preparing... ########################################### [100%]
package glibc-2.12-1.47.el6_2.9.i686 is already installed
[root#localhost Excluded]# ls *.rpm
glibc-2.12-1.47.el6_2.9.i686.rpm libgcc-4.4.6-3.el6.i686.rpm
[root#localhost Excluded]# rpm -ivh libgcc-4.4.6-3.el6.i686.rpm
Preparing... ########################################### [100%]
package libgcc-4.4.6-3.el6.i686 is already installed
[root#localhost Excluded]# rpm -ivh libstdc++-4.4.6-3.el6.i686.rpm
warning: libstdc++-4.4.6-3.el6.i686.rpm: Header V4 DSA/SHA1 Signature, key ID 192a7d7d: NOKEY
Preparing... ########################################### [100%]
package libstdc++-4.4.6-3.el6.i686 is already installed
file /usr/lib/libstdc++.so.6.0.13 from install of libstdc++-4.4.6-3.el6.i686 conflicts with file from package libstdc++-4.4.6-3.el6.i686
Why GDB cannot find it?
Question: Do I have to worry about this issue? If not, how to turn it off? If yes, how to fix it?
Thank you
debuginfo-install is a command of yum-utils, so
yum install yum-utils
debuginfo-install glibc
if the warning's still there, edit /etc/yum.repos.d/CentOS-Debuginfo.repo, set enabled=1
In case, someone else encounters the same issue,
I had updated the glibc and somehow the old ldconfig had been flushed
was facing this error while running the application
error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory
Even after setting the LD_LIBRARY_PATH it didn't work:
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH
Finally the commands below came to the rescue.
// Add you library path here.
echo /usr/local/lib >> /etc/ld.so.conf
// And then Run ldconfig to reflect the path
ldconfig
The order of the accepted answer doesn't work for me.
I followed some tips in the comments and here's what I tried and succceded in my fresh install CentOS 7.2
From #lkraav's comment, I followed this wiki https://wiki.centos.org/AdditionalResources/Repositories/DebugInfo and create a new file.
The following could be appended to /etc/yum.repos.d/CentOS-Base.repo or a new file created such as /etc/yum.repos.d/CentOS-Debug.repo.
I pasted those contents from the wiki into the new /etc/yum.repos.d/CentOS-Debug.repo file but edit enabled=0 line to enabled=1
I debuginfo-install everything showed in the gdb warning and succeeded installing.