When I run a executive file using gdb, a failure is issued like the following.
Cannot parse expression `.L1185 4#r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
GDB Version : GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
How could I fix it?
Related
I'm using Eclipse 2021-09 (4.21.0) for C++, g++9, gdb9 under Ubuntu 20.04 and I'm sometimes unable to see variables content in Eclipse.
For standard type variables (boolean, int,...) it's OK, but for pointers it fails.
I get the following error:
Multiple error reported.
1) Connection is shut down
2) Unable to create variable object
It looks like that gdb fails because the debugged program stops !?
Here are some details:
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
The gdp process line (using ps): gdb --interpreter mi2 --nx -q --interpreter console -ex new-ui mi /dev/pts/1 -ex set pagination off -ex show version
Any idea? I'm stuck.
I was affected by this too, and spend time tracking down the issue to a gdb bug, which turns out to be known & fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=28711
The problem seems to come from gdb 9.2. Using gdb 8.3 whe have no more problem.
Is there anyway to debug a link error or any kind of error that may occur before the execution of the main() function using GDB?
Is there anyway to debug a link error
Presumably you are asking about runtime link error (e.g. `error: libfoo.so: no such file or directory'), and not about (static) link step of your build process.
The trick is to set a breakpoint on exit or (exit_group on Linux) system call with e.g. catch syscall exit. You will then be stopped inside ld.so at the point where it gives up running your binary.
or any kind of error that may occur before the execution of the main() function using GDB?
Any other kind of error, e.g. SIGSEGV can be debugged "normally" -- for signal you don't need to do anything at all -- GDB will just stop. For other errors, just set a breakpoint as usual.
On way to debug initialization code (even if you don't have symbols) goes like this:
gdb somebinary
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
etc.
info file
Symbols from "somebinary".
Local exec file:
`/somebinary', file type elf64-x86-64.
Entry point: 0x4045a4, etc.
break *0x4045a4
run
...Breakpoint 1, 0x00000000004045a4 in ?? ()
From here on you can proceed as usual.
I am using Clang compiler and created an executable with it. I am trying to debug using GDB. However, while initializing gdb with,
gdb executable core
I am receiving the following error,
Dwarf Error: Cannot handle DW_FORM_flag_present in DWARF reader [in module /xxx/yyy/executable]
Does anyone have idea about this error?
Your gdb is too old. DW_FORM_flag_present is a DWARF 4 feature. Support for it was added to gdb in April, 2010. At least, that is true for the GNU gdb. I don't know when, or whether, this was added to Apple's fork of gdb.
I tried running GDB, version 7.6.50.20130508-cvs (cygwin-special), on Xemacs version 21.4.21 but I get the following error:
/netrel/src/gdb-7.6.50-2/gdb/cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed
A problem internal to GDB has been detected,
further debugging may prove unreliable
GDB by itself works fine on Cygwin. On the Cygwin terminal, I did:
g++ -g -o HelloWorld HelloWorld.cpp
to get the executable, and wrote
gdb HelloWorld.exe
and then
r
and it worked perfectly. I then did
gdb -v
and the version turned out to be the same as the gdb used by xemacs, so it seems that the error must be related to the interaction of gdb and xemacs, instead of it being a gdb problem?
I found that some people had the same, or similar, issue:
http://old.nabble.com/-RFA--dangling-cleanup-in-find_frame_funname-td35521450.html
Any ideas? Thanks in advance!
Also, does anyone know where is the cleanups.c file located? I can't even find the netrel folder (it certainly is not located in the / folder in Cygwin).
instead of it being a gdb problem?
It is a GDB problem (internal assert is failing), and you should report it in GDB bugzilla if you can reproduce it with current HEAD CVS revision.
the error must be related to the interaction of gdb and xemacs
Emacs interacts with GDB in MI mode. But it's still a GDB bug.
I have just moved from Ubuntu 10.04 to the new version of 11.04 and when I try to debug with ddd/gdb I cannot set anymore breakpoints nor see the flow while the debugger is executing my program.
I receive error messages saying
(gdb)b MyFile.cpp:27
No line 27 in file "MyFile.cpp".
When I start running my application calling r I also can see the following text message that looks to me related to my issue. The debuggers traps all assertions but I cannot stop at any point.
(gdb) r
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
If I want to see the file, the debuggers open the file with me but I receive the following error message
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
Can you help me?
I read some forum asking to check the result of info source and info sources and this is what I have but I don't know what to do with it.
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
(gdb) info source
Current source file is /usr/local/include/boost/exception/exception.hpp
Compilation directory is /home/emanueler/trunk/tools/myAppBinary
Located in /usr/local/include/boost/exception/exception.hpp
Contains 436 lines.
Source language is c++.
Compiled with unknown debugging format.
Includes preprocessor macro info.
Why it says "Compiled with unknown debugging format." when I am giving the -g option at compiler?
It seems all the compiling related tools were also updated, including GCC. It would be best if you recompile your entire application in this new environment before trying to debug it again.
You can do a simple test for check that your toolchain is ok. Write a small hello world app, compile it with -g and try to set a breakpoint on the cout line.