I start by giving the binary file to gdb.
There on, now inside gdb, I say
(gdb) core corefile
>warning: core file may not match specified executable file
>New thread ##
>New thread ##
>New thread ##
>New thread ##
Prompt returns ( gdb has quit here)
realised that I was using the wrong Binary.
The waring was indeed correct and required more serious perspective from me.
Related
I'm performing post mortem debugging on a core file. The build was done such that the location of the source code is referenced as ../../../../../_vcs in the core. I placed the source code in /_vcs (that is, at root). However, I cannot get the set substitute-path gdb command to work. How is this supposed to be invoked?
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
Copyright (C) 2013 Free Software Foundation, Inc.
...
Program terminated with signal 6, Aborted.
#0 0x00007f9f6fd37207 in raise () from /lib64/libc.so.6
(gdb) f 2
#2 0x000000000042c585 in SignalHandler (sig=11) at ../../../../../_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc:935
935 ../../../../../_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc: No such file or directory.
(gdb) set substitute-path ../../../../../ /
(gdb) l
930 ../../../../../_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc: No such file or directory.
(gdb) set substitute-path ../../../../../_vcs /_vcs
(gdb) l
930 ../../../../../_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc: No such file or directory.
(gdb) quit
-bash-4.2$ ls /_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc
/_vcs/trafficserver9/src/traffic_manager/traffic_manager.cc
Note that I can list the file at the specified location after I manually substitute ../../../../../_vcs with /_vcs. What am I doing wrong? Do I have to escape parts of the path?
(As a side note, I can work around this problem via cd /. Then the indirect ../ references stop at / and I can access the directory. But it seems to me that set substitute-path should address this as well.)
Perhaps this isn't a workaround that works in all cases, but I happened to have a directory that was as deep in the source tree as the original binary was compiled in. (And if I didn't have such a directory, I could have made one.) So, I used the gdb command cd into a place that the compiled-in path ../../foo/bar/file.cpp would actually find the code.
At that point the gdb command list showed the source correctly.
Trying out DDD for the first time in conjunction with some C++ code I already have written and compiled on another machine. When I run DD with the code, I get this error:
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
terminate called after throwing an instance of 'std::runtime_error'
what(): User configuration file not found
Program received signal SIGABRT, Aborted.
0x00007ffff6f84428 in __GT_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 (gdb)
Not sure what to think, as I have the code built and running on an RPi. Any help would be most appreciated!
When I run DD with the code, I get this error
That is an error from your program (which throws exception).
You can find out where that error is coming from using the GDB where command.
If your program doesn't throw this exception when you run it outside of DDD, it's likely that your program looks for "configuration file" in its current directory (bad idea (TM)), and that the directory in which you start it is different from the directory in which DDD starts it.
You can use cd command inside DDD to change the current directory, and this will likely "fix it" for you (but really you should fix your program so that it uses $HOME or some other well defined location for its configuration files).
I'm currently running a file manager program that abruptly crashed with a segmentation fault and dumped a core file. So I used gdb to debug the core file as:
gdb /path/to/executable /path/to/core
The program which I was running is written in C++. When I ran GDB and tried to print the source lines using "list", I got the following error:
(gdb) bt
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
#1 0x00000000005ab2e8 in
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&) ()
(gdb) f 0
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
(gdb) l
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory." I do not hit this issue with some other programs that I've debugged using gdb.
The operating system used is Ubuntu 16.04 running on Oracle virtual box. I think may be the gdb symbols were not loaded. I'm not sure why since I compiled the program using the "-g" option. I really need to know the source lines where the code crashes via gdb.
Any suggestions?
EDIT: changes after suggestions from Employed Russian
I was compiling my main using "-g" option and linking it to "existing" object files which were obviously not compiled using "-g" so when the core dumped, I could not see the source for these files. So I went ahead and recompiled those files with "-g" option and reproduced the core dump. It's able to show me the source lines now.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."
Because you really don't have that file on your system.
I think may be the gdb symbols were not loaded
GDB did load debug symbols for glib, but not for your main executable.
I'm not sure why since I compiled the program using the "-g" option.
Since we don't have your compile and link lines, we can't tell exactly what's wrong, but some of the common issues are:
You have a "stray" -s or -Wl,-s on your link line (this strips debug info from the resulting binary).
You have -g when compiling your main.c, but not when compiling the source in which MyFSEventManager::AddEvent() is defined
P.S.
(gdb) bt
This doesn't seem to be the complete output from bt command. Always try to paste complete outputs as it makes helping easier :)
I want to load shared library (.so) from gdb, I found this command :
(gdb) call dlopen("path/to/lib.so",..)
But it doesn't work, I link my program with -ldl.
The error I get is:
No symbol "dlopen" in current context
what did I miss ?
I found a command that resolve the half of this topic. I explain:
First, you should load the shared object into the process:
(gdb) set environment LD_PRELOAD /usr/lib/libdl.so
After that, we define the file to debbuging
(gdb) file pgm
For testing, we put breakpoint in main i.e
(gdb) break main
Now, we run the program
(gdb) run
and we call dlopen
(gdb) call dlopen("/path/to/lib.so",2)
until now it's work, but when I put the last command, I have:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de7f09 in ?? () from /lib64/ld-linux-x86-64.so.2
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
(_gdb_expr) will be abandoned.
When the function is done executing, GDB will silently stop.
nothing changes when I modify 'unwindonsignal to (on/off)'
What did I forget this time ?
useful
"Bus Error" doesn't tell me much so I want to access the core file to find out where it went wrong. I try to do this:
(gdb) core core
/this/is/my/directory/Program/core: No such file or directory
(gdb)
but it says there is no directory. I compile my program using Qt on mac and it does not produce anything called 'core'. Any advice on how to debug this?
Thank you.
I don't use a Mac, but it seems like core files are either suppressed by default or written to a dedicated directory. You could copy the core file to your program directory and invoke gdb with the excecutable and core file name:
Where are core dumps written in Mac OS X?
GDB: http://www.gnu.org/software/gdb/documentation/
gdb <program_name> <core_file_name>