Running GDB 7.4-2012.02 on Ubuntu and am experiencing weird behavior that I can't duplicate on other platforms.
bash$ export LD_LIBRARY_PATH=my_path
bash$ export LD_LIBRARY_PATH2=my_path2
bash$ gdb
GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 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".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb) shell echo $LD_LIBRARY_PATH
(gdb) shell echo $LD_LIBRARY_PATH2
my_path2
As can be seen, GDB is resetting LD_LIBRARY_PATH but none of the other exported variables. Why is it doing this? Is there some setting I don't know about which causes this? My ~/.gdbinit is empty and the behavior persists even when using gdb -n.
Additionally, after exiting back to the login shell:
bash$ echo $LD_LIBRARY_PATH
my_path
bash$ $SHELL -c 'echo $LD_LIBRARY_PATH'
my_path
bash$ $SHELL
hi from .bashrc
bash$ echo $LD_LIBRARY_PATH
my_path
So I don't think my startup scripts are the issue.
So I don't think my startup scripts are the issue.
Yes, they are the issue (I know for a fact that GDB does not mess with your LD_LIBRARY_PATH environment).
Update:
Startup scripts were not the issue after all.
After some debugging, user2601195 discovered that the following variables were all getting unset: GCONV_PATH, GETCONF_DIR, HOSTALIASES, LD_AUDIT, LD_DEBUG, LD_DEBUG_OUTPUT, LD_DYNAMIC_WEAK, LD_LIBRARY_PATH, LD_ORIGIN_PATH, LD_PRELOAD
These are environment variables that glibc considers insecure, and unsets for setuid binaries. It turned out that in fact the gdb being invoked was suid-root:
-rwsr-sr-x 1 root root 5975928 Mar 15 2012 /usr/bin/gdb
which explains the problem.
Related
Long story short - LLDB doesn't debug my program properly, so I need to use GDB on my Mac to debug a c++ project. Steps I've taken:
Install GDB 8.0.1 and 8.1 via brew/macports (ie try all options)
Codesign the binary properly.
Start the mac in restart mode and typing csrutil enable --without debug
Choose the custom GDB executable in Clion.
Write in the .gdbinit file located in the home directory set startup-with-shell off
When I go to debug in Clion, in the debugger window it reads:
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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-darwin17.2.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".
[New Thread 0x2203 of process 1208]
warning: unhandled dyld version (15)
In the console window it just prints the path of the executable and then hangs there until eventually it says 'command timed out'.
Any ideas would be massively appreciated.
I'm using WSL(Bash on Windows = Windows Subsystem for Linux).
I wrote a simple code, a.c
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello\n");
return 0;
}
I compiled it.
$ gcc -g -o a.exe a.c
$
It worked well.
$ ./a.exe
Hello
$
And, I tried to execute a.exe in gdb. However, I got "During startup program exited normally."
$ gdb ./a.exe
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
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-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 ./a.exe...done.
(gdb) r
Starting program: /home/softgear/a.exe
During startup program exited normally.
(gdb)
How can I use gdb in WSL? Help me, please.
Looks like this is already reported and fixed WSL bug.
As a workaround you can set disable-randomization off before debugging, see https://github.com/Microsoft/WSL/issues/2870#issuecomment-359664608. Or update WSL to a latest version.
I am trying to debug a simple "hello world" C++ program on Ubuntu 16.04 but gdb is not able to recognize the executable file format. However, I am able to successfully run the executable on the command line.
Here is the code
#include <iostream>
using namespace std;
int main() {
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
I compile the program file TestProject.cpp using the command
g++ -g TestProject.cpp -o hello
Then to debug, I give the command
gdb ./hello
I get the following error message
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
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 "i686-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"...
"/home/<home>/./hello": not in executable format: File format not recognized
Something seems to be corrupt with the Ubuntu machine. Because I am able to debug the same program on another Ubuntu 16.04 virtual machine.
It is almost certain that ks1322's comment is correct one:
You've installed a 64-bit GCC, so your ./hello is a 64-bit binary (use file ./hello to confirm).
You've installed a 32-bit only GDB, so it doesn't know how to debug x86_64 binaries.
The fix is simple: install 64-bit GDB (which is capable of debugging both 32 and 64-bit binaries), or build hello in 32-bit mode (with g++ -m32 ...).
I had the same issue on mac os.
there is a bug in gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=23746
their git repository has already had the fix. Unfortunately, the bins in homebrew have not had it yet. So, I had to git clone git://sourceware.org/git/binutils-gdb.git, compiled it and installed as it is described in the readme file.
I do believe this will fix yours on ubuntu.
P.S. it works on my machine but I have to run eclipse as root:
sudo /.../MacOS/eclipse. Otherwise, I have Launching : Configuring GDB Aborting configuring GDB. Cause I do not know how to fix it (
When trying to run gdb with a program, it seg faults while reading symbols.
When I run:
gdb /home/user/path/to/program.exe
I get:
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 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-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 /home/user/path/to/program.exe...Segmentation fault (core dumped)
I suspect that the binary might be too large for gdb to load into memory. This error only occurs when I compile with -g (debug flag). Here's the difference in size of the binaries:
Compiled with
-release flag: 405 MB
-debug flag: 862 MB
Any ideas on other culprits of this segmentation fault? Or is there a way to increase the memory allowed for gdb? This turns out to be a very challenging problem to google.
I was having the same problem with gdb 7.9 on Ubuntu 15.04 x86_64, which I had installed simply using apt-get install gdb.
I solved the problem by compiling and installing a previous version: gdb 7.5.1.
I had to download a library (which I found out here) and I also had to run ./configure using some arguments (which I found out here). Everything else is straightforward.
Good luck.
Here are the commands:
$ cd
$ sudo apt-get install libncurses5-dev
$ wget ftp://sourceware.org/pub/gdb/releases/gdb-7.5.1.tar.gz
$ tar zxf gdb-7.5.1.tar.gz
$ cd gdb-7.5.1
$ sudo ./configure --disable-werror
$ sudo make
$ sudo make install
If you compile without the -g flag then you are not including debugging information in your executable, so when gdb loads there's much less information to load in.
If gdb segfaults during start up then this is a gdb bug, there's no executable that you should be able to pass to gdb that should cause a segfault, at worst you should get some error message.
You could try running gdb under gdb, (just do gdb --args gdb /home/user/path/to/program.exe) this will not help you much, but might give some insight into what is wrong with gdb, you could then file a gdb bug here: https://sourceware.org/bugzilla/enter_bug.cgi?product=gdb but this is only worth doing if you either have good steps to reproduce, or a backtrace from a crashed gdb.
Reinstalling gdb might help, but I wouldn't hold much hope of that solving the problem, unless you change the version of gdb you install, gdb itself is a pretty easy program to install, so pretty hard to get wrong.
You could also try building gdb from git, it's pretty easy, and the bug might have already been fixed, start from here: http://www.gnu.org/software/gdb/current/
If you extend your question with a backtrace from a crashed gdb then others might be able to offer you more of an insight into why this is crashing, but the blame is definitely with your version of gdb.
I'm trying to read an ARM core file on my Linux desktop, but it seems not to be able to figure out my core file. Is there any way I can instruct gdb what type my core file is?
$ file ~/daemon
./daemon: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
$ file ~/core
./core: ELF 32-bit LSB core file ARM, version 1 (SYSV), SVR4-style, from './daemon -v -v -v -v -e 10 -t foo'
$ gdb-multiarch ~/daemon ~/core
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ./daemon...done.
"./core" is not a core dump: File format is ambiguous
(gdb) core-file ~/core
"./core" is not a core dump: File format is ambiguous
The generating platform is armv4, which gdb-multiarch claim to support, according to the "set architecture" list.
EDIT: To clarify, my desktop machine running gdb is "x86_64-linux-gnu", namely an 64-bit Intel Ubuntu box.
This may help:
$ gdb-multiarch
...
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set gnutarget elf32-littlearm
(gdb) file daemon
...
(gdb) target core core
...
(gdb)
The following is relevant only if your desktop (where you are trying to run gdb-multiarch) is x86.
Gdb is a debugger. As such it will not be able to debug a foreign architecture executable on your x86 desktop machine because you cannot run arm code on x86 processor. You can however debug it remotely using gdb-server which will run on arm machine.
Is your desktop arm or x86?