I know this is a very common problem, but I tried a lot of stuff, I no one give me a solution. I have a program in C++ with C::B, and I cannot debug. I have the tick in the "-g" option at the "Build Options" in my project. And I have the "gdb.exe" as debugger. But the result is this:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Release
Adding source dir: I:\Juego para practicar\
Adding source dir: I:\Juego para practicar\
Adding file: bin\Release\Juego para practicar.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
**(no debugging symbols found)...(gdb)**
Debugger name and version: GNU gdb 5.2.1
No symbol table is loaded. Use the "file" command.
Program exited with code 030000000472.
Debugger finished with status 0
What can I do? I proved everything, but it remains with no debugging.
"..
Selecting target:
Release
.."
You are in release build, try to rebuild in debug
Paste your buildlog showing us that you are getting the correct compiler flags.
For example, you should have -g for producing symbols.. You shouldn't have -s (strip) which removes all symbols not needed for relocations, etc.
Related
I have just installed codelite in my windows 8.1.It shows error
Debugger exited with the following error string:
"No executable
specified,use 'target exec'"
I searched and found this (another stackoverflow question) I did the same as mentioned there but nothing really worked for me.I made a new project and selected Simple executable (g++) and GNU debugger as default debugger.Can anybody help me with this.Also it shows "Program exited with return code: 4199040".
It seems that you don't provide executable to run/debug:
Go to
Project settings... -> Common settings -> General
and fill correct information for
Executable to Run / Debug
Jarod42 provided a 'close enough' answer. On Linux the steps seem to be:
Workspace -> Open Active Project Settings... -> General
and fill correct information for
Executable to Run / Debug
In the command prompt:
gdb (program type: example python or c or c++ etc)
If am running python program then the command will be gdb python
then (gdb) run program_name.py
I'm using codeblock to test two projects. In one project everything is right, I can both run and debug the code. However in another project I can only run the code but could not debug. I set up breakpoint and begin debug, but it doesn't stop at the breakpoint. Could anyone tell me what might be wrong here?
I searched and find this thread Codeblocks "Error resetting breakpoint..." can't debug
and I've make sure there is no space in my project file names.
The following is from the Debugger
Starting debugger: C:\Program Files (x86)\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname -quiet -args D:/SOFTWA~1/C__~1/LEARNC~1/SELECT~1/bin/Debug/SELECT~1.EXE
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
(no debugging symbols found)
Debugger name and version: GNU gdb 6.8
Child process PID: 12992
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Program exited normally.
Debugger finished with status 0
no debugging symbols found,it tells you that you should add -g option when you compile the project.
I have a node.js module written in C++ that provides some bindings for a C++ library. The library crashes with SIGSEGV, so I need to debug it with GDB and find out what goes wrong.
I already have the source for the module in ./node_modules/somelib/ and if I go to that folder and type npm install the library is compiled and can be used through a require('somelib') from node.js. I can attach gdb to node and reproduce the error, but in the stacktrace I just see node_modules/somelib/Release/somelib.node.
I'm not sure if this is important but the library is compiled using node-gyp.
Question 1: How do I load the source code or point gdb to the source code?
Question 2: How do I configure node-gyp to produce debug symbols?
I just found the answer to this in the node-gyp documentation. The solution is to invoke the build process with the --debug flag. That means to invoke node-gyp configure --debug and/or node-gyp build --debug. Then instead of a Release folder a Debug folder will be created. gdb will then automatically load the source files.
Shamelessly copied from an archive of the (now broken) link provided by #Peter Cordes
First, compile your add-on using node-gyp with the --debug flag.
$ node-gyp --debug configure rebuild
Second, if you're still in "playground" mode like I am, you're probably loading your module with something like
var ObjModule = require('./ObjModule/build/Release/objModule');
However, when you rebuild using node-gyp in debug mode, node-gyp throws away the Release version and creates a Debug version instead. So update the module path:
var ObjModule = require('./ObjModule/build/Debug/objModule');
Alright, now we're ready to debug our C++ add-on. Run gdb against the node binary, which is a C++ application. Now, node itself doesn't know about your add-on, so when you try to set a breakpoint on your add-on function (in this case, StringReverse) it complains that the specific function is not defined. Fear not, your add-on is part of the "future shared library load" it refers to, and will be loaded once you require() your add-on in JavaScript.
$ gdb node
...
Reading symbols from node...done.
(gdb) break StringReverse
Function "StringReverse" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
OK, now we just have to run the application:
(gdb) run ../modTest.js
...
Breakpoint 1, StringReverse (args=...) at ../objModule.cpp:49
You can add the directory containing the source of the module to gdb's search path:
(gdb) directory /path/to/source
See: http://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html
Also, to get node-gyp debug symbols, install node-gyp-dbg/dev or equivalent, or compile it with -g
If you are a VSCode user, you may find this helpful inorder to debug your module.
Basic steps are:
Install the vscode plugin https://github.com/vadimcn/vscode-lldb
Setup your launch.json to look like this :
{
"version": "0.2.0",
"configurations": [{
"type": "lldb",
"request": "launch",
"name": "Launch Program",
"program": "/absolute/path/to/node",
"args": [
"/absolute/path/to/your/index.js"
]
}]
}
Then setup breakpoints as you would in VS Code.
Happy debugging!
I have also published a detailed blog here if you want more detailed explanation.
https://medium.com/#atulanand94/debugging-nodejs-c-addons-using-vs-code-27e9940fc3ad
Before explaining my problem:
My OS is Ubuntu 12.04 LTS 32bits with 4GB RAM.
My IDE is Code::Blocks 12.11(I've had the same problem with 10.05)
I'm using the GNU GCC Compiler with the -g flag and the -std=c++0x flag.
When trying to debug this program:
using namespace std;
#include<iostream>
int main(){
int n=10;
for(int i=1;i<=n;i++){
int ax=i;
while(ax) ax--;
cout<<i;
}
return 0;
}
I can't get anything to happen,if I try the "Run to cursor" command or if I try to use breakpoints. They just get skipped and my program finishes running.
This is what I get in the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding file: /home/classius/CodeBlocks/Dr/bin/Release/Dr
Changing directory to: /home/classius/CodeBlocks/Dr/.
Set variable: LD_LIBRARY_PATH=.:
Starting debugger: /usr/bin/gdb -nx -fullname -quiet -args /home/classius/CodeBlocks/Dr/bin/Release/Dr
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
No symbol table is loaded. Use the "file" command.
Temporary breakpoint 2 ("/home/classius/CodeBlocks/Dr/main.cpp:10) pending.
[Inferior 1 (process 13381) exited normally]
Debugger finished with status 0
If anyone wants to suggest a solution that implies using the terminal, please do it in the most noob-orieted terms you can find!
PS: How to add breaklines on stack-overflow when asking a question?(Solved-Thanks!)
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no
debugging symbols found)...done.
This means you didn't have the -g option during compilation.
UPDATE:
file /home/classius/CodeBlocks/Dr/bin/Release/Dr
/home/classius/CodeBlocks/Dr/bin/Release/Dr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7da8c5cff4af5082d82eecc3ede59a5920b253a0, stripped
So it's 'stripped', which means -g option was not really used. You may recheck your compiler config or try to build the Debug version?
in settings menu choose debugger then gdb-cdb tab and then reset default
I'm working on RHEL WS 4.5.
I've obtained the glibc source rpm matching this system, opened it to get its contents using rpm2cpio.
Working in that tree, I've created a patch to mtrace.c (i want to add more stack backtrace levels) and incorporated it in the spec file and created a new set of RPMs including the debuginfo rpms.
I installed all of these on a test vm (created from the same RH base image) and can confirm that my changes are included.
But with more complex executions, I crash in mtrace.c ... but gdb can't find the debug information so I don't get line number info and I can't actually debug the failure.
Based on dates, I think I can confirm that the debug information is installed on the test system in /usr/src/debug/glibc-2.3.6/
I tried
sharedlibrary libc*
in gdb and it tells me the symbols are already loaded.
My test includes a locally built python and full symbols are found for python.
My sense is that perhaps glibc isn't being built under rpmbuild with debug enabled. I've reviewed the glibc.spec file and even built with
_enable_debug_packages
defined as 1 which looked like it might influence the result. My review of the configure scripts invoked during the rpmbuild build step didn't give me any hints.
Hmmmm .. just found /usr/lib/debug/lib/libc-2.3.4.so.debug
and /usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug
but both of these are reported as stripped by the file command.
It appears that you are installing non-matching RPMs:
/usr/src/debug/glibc-2.3.6
just found /usr/lib/debug/lib/libc-2.3.4.so.debug
There are not for the same version; there is no way they came from the same -debuginfo RPM.
both of these are reported as stripped by the file command.
These should not show as stripped. Either they were not built correctly, or your strip is busted.
Also note that you don't actually have to get all of this working to debug your problem. In the RPMBUILD directory, you should be able to find the glibc build directory, with full-debug libc.so.6. Just copy that library into your VM, and you wouldn't have to worry about the debuginfo RPM.
Try verifying that debug info for mtrace.c is indeed present. First see if the separate debug info for GLIBC knows about a compilation unit called mtrace.c:
$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug > t
$ grep mtrace t
name (strp) "mtrace.c"
name (strp) "mtrace"
1 0 0 0 mtrace.c
[10480] "mtrace.c"
[104bb] "mtrace"
[5052] symbol: mtrace, CUs: 446
Then see if GDB actually finds the source file from the glibc-debuginfo RPM:
(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources
Quit GDB then grep for mtrace in gdb.txt and you should find something like /usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c
This works with GDB 7.4. I'm not sure the GDB version shipped with RHEL 4.5 supports all the command used above. Building upstream GDB from source is in fact easier than Python though.
When trying to add strack traces to mtrace, make sure you don't call malloc() directly or indirectly in the GLIBC malloc hooks.