I keep getting "No symbol table is loaded" error while working on my GDB session.
I complied my source files using the following command :
$ gcc -g -Wall -o test exc4.3_modulus.c getop.c stack.c
When I started my GDB session as:
$ gdb test -tui
and tried to add a break point at getop function inside getop.c as
(gdb) b getop.c:getop
GDB is showing the following error:
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or n)
I browsed over stackoverflow and found this thread
[gdb: "No symbol table is loaded"
As suggested in the thread and in the gdb session I tried
(gdb) file test
But what I get as an outcome is not an improvement over the scenario
Reading symbols from /usr/bin/test...(no debugging symbols found)...done.
and problem with the break point still persists.
Can anyone point me out where I am going wrong? I am new to GDB. So an proper explanation would always be greeted thankfully.
PS : The problem is solved after I updated my GCC and GDB.
Related
I was trying to learn how to use gdb on core dumps.
Here is the code:
int main()
{
return 1/0;
}
This is the gdb output, when I run gdb a.out core:
warning: exec file is newer than core file.
[New LWP 3121]
Core was generated by `./crash'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x00000000004004fc in ?? ()
(gdb) bt
#0 0x00000000004004fc in ?? ()
#1 0x0000000000400500 in ?? ()
#2 0x00007f6ea0945b97 in ?? ()
#3 0x0000000000000000 in ?? ()
What are ?? in the backtrace? How can I resolve them?
Those ?? are usually where the name of the function is displayed. GDB does not know the name of those functions and therefore displays ??.
Now, why is this happening? Depends. GCC compiles including symbols (e.g. function names and similar) by default. Most probably you are working with a stripped version, where symbols have been removed, or just with the wrong file.
As #zwol suggests, the line you see warning: exec file is newer than core file is an indication of the fact that something else is going on that you don't show in your question. You are working on a core dump file generated by the crashed executable, which is outdated.
I would suggest you to re-compile the program from scratch and make sure that you are opening the right file with GDB. First produce a new core dump by crashing the new program, then open it in GDB.
Assuming the following program.c:
int main(void) { return 1/0; }
This should work:
$ rm -f core
$ gcc program.c -o program
$ ./program
Floating point exception (core dumped)
$ gdb program core
Reading symbols from program...(no debugging symbols found)...done.
[New LWP 11896]
Core was generated by `./program'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x000055d24a4cd790 in main ()
(gdb) bt
#0 0x000055d24a4cd790 in main ()
(gdb)
NOTE: if you don't see (core dumped) when running the process that means that a core dump was not generated (which leaves you with the old one). If you are using Bash, try running the command ulimit -c unlimited before crashing the program.
What does ?? in gdb backtrace mean
It means that GDB has no idea to which code the addresses in backtrace: 0x04004fc, 0x0400500, etc. correspond.
and how to get the actual stack frames?
That depends on why this is happening. There are two common scenarios:
You are debugging the wrong executable.
One way this could happen is when you compile with optimization, e.g. gcc -O2 main.c -o crash, let the program dump core, then recompile with debugging (e.g. gcc -g main.c -o crash) and try to debug "old" core dump with "new" executable.
Don't do that. Instead, compile with optimization and debugging: gcc -O2 -g main.c -o crash.
P.S. This warning: warning: exec file is newer than core file is intended to warn you precisely about this case.
The other common cause is when you obtain a crash on a production system and try to debug it on a development one (given the addresses which you show this is unlikely to have happened here).
For that case, see this answer.
You did not compile with debug symbols - try adding -g to the compile line
I have been given a binary file with embedded C code which I cannot see when I run it in the GDB GCC Debugger. I imagine the C code has been hidden by the compilation / formation of the binary code. I have tried the following:
gdb> file myFile
gdb> list main
The output I get is:
myFile.c: No such file or directory
I know there is code written in C in this binary file. The executable runs when I type ./myFile
I have installed 32-bit libraries as this is needed for this situation and I'm running Ubuntu 16.04
Any help is appreciated.
It could be are a compilation issue. Try to look option for debugging
$ gcc -g myFile.c -o myFile
$ gdb myFile
(gdb) list main
If you compile without "-g" option, the debugger will never show you th C code but only the assembly code.
In your case, if you run these commands, you will see the disassembled code
(gdb) info file
Then take the address of the entry point
Entry point: 0x(address)
For show disassembly code
(gdb) break 0x(address)
(gdb) run
When the breakpoint gets caught
(gdb) x/20i $pc
after trying a couple of alternatives to debug a exe fairly unsuccessfully decided to try gdb to debug a executable on the windows env.
The options that are being used to compile the exe look like this
/nologo /Z7 /Zi /MT /W3 /GX /O2 /D /DEBUG
These are the options that I am using to load the executable into gdb
target exec setup
run -debug ( this is the option against which I would like to perform some debugging)
I need a way to either load the source/symbols into GDB since I am unable to set any valid breakpoints otherwise.
This is what I have tried, in order to set breakpoints ( other than the usual way)
(gdb) set breakpoint pending on
(gdb) break runInstaller.c:6318
No symbol table is loaded. Use the "file" command.
Breakpoint 2 (runInstaller.c:6318) pending.
(gdb) pwd
Working directory C:\
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> WinMain
2 breakpoint keep y <PENDING> runInstaller.c:6318
I have tried this to load the executable;
(gdb) file setup
Reading symbols from setup...(no debugging symbols found)...done.
It is due to the above errors I realise that the executable is not compiled with the debugging options, so it there a gcc -g equivalent in gdb or are there better way s of loading the symbols/source code into gdb.
Edit 1:
Whenever I try to add a breakpoint I see the following error:
(gdb) b main_helper
Function "main_helper" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 5 (main_helper) pending.
The setup file which you are currently using does not have the symbol table which is required to debug. When you are generating the executable binary you need to generate the symbol table as well.
Ex. when we are generating the executable file for a c program we compile with the argument -g.
gcc setup.c -o setup -g
-g tells the gcc compiler to generate the symbol table.
I am using gdb for debugging C project source code. I compile as shown:
./configure --enable-debug CFLAGS="-g -o0"
make --debug=a
I want to debugging stop at specific file. So when I set break point by using
(gdb) break main.c:672
It says:
No source file named main.c.
Even when I pass specific function name (in main.c file) to break . it says: such function not defined.
My current directory has this main.c file. I am using Cygwin on Windows. When I set break point by using
(gdb) break main
It set break point at a main function of Cygwin file, not in my source code.
how can I fix my first problem?
just curious, how to avoid second problem, if there is same function name within Cygwin files and my source code?
When you compile your .c file, make sure you use:
gcc filename.c -g
gdb <binary name>
Search for load debugging symbols done or not?
If not:
gdb) symbol-file <path-of-symbol-file>
you can find symbol file in obj directory
If you're compiling with -g and still not able to set a breakpoint, try adding raise(SIGTRAP) in your main(), run the process in gdb, then set the breakpoint you want again after it hits the SIGTRAP.
Crucial is gcc parameter -g during compilation.
Everything else is secondary.
See breakpoints in GDB
I also encountered with similar problem earlier. I just deleted .metadata folder and imported the particular project again and that work well.
Whenever you have to use GDB, type the following in command line
gcc -g -o outputfile sourcefile.c
Now type
gdb -tui outputfile
and then enter the break command
To create the .out executable, I have to enter:
$: make
$: myprogram.out name.ged
My program incorporates a command line argument, thus the "name.ged".
Whenever I run gdb after getting a segmentation fault (core dumped), I enter:
$: gdb a.out core
(gdb): bt
I then use the back trace command, and gdb returns:
#0 0x4a145155 in ?? ()
#1 0x08a16ce0 in ?? ()
I even tried using the up command t move up the stack, but still no luck. I can't tell which line in my program is giving me the seg fault. gdb works with my other programs that do not involve a Makefile and command arguments, so I'm wondering if my commands are incorrect.
Summarizing the comments (before anyone else does :).
Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.
In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.
CFLAGS= -g -Wall -Wextra
You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).
$ CFLAGS='-g -Wall -Wextra' make
I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.
CFLAGS='-Wall -Wextra'
Then, when you need it, put this in the makefile to make a debuggable executable:
CFLAGS+= -g