How to debug binary module of nodejs? - c++

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

Related

Visual Studio Code Debug: source and then launch on same shell

My current workflow for a project is the following:
build the project (via catkin)
source a setup.sh script (generated by catkin, which I wouldn't like to modify) setting environment variables and the names needed by my executable.
Run "MyProgram", which is only available after sourcing the "setup.sh" script.
I would like to be able to debug my project in Visual Studio Code. To do this, I have defined a task building the executable via catkin, named "catkin build all", and I have defined a second task as:
{
"type": "shell",
"label": "load programs",
"command": "source /some_folder/setup.sh",
"group": "build",
"dependsOn": ["catkin build all"]
}
Which is the "preLaunchTask" of my lanuch.json launch configuration.
Launching debug will correctly compile the project, but execution fails with error "launch: program myProgram does not exist". Indeed program MyProgram can not be found if setup.sh is not sourced, but is should be sourced by the "preLaunchTask".
In my launch.json i can also set "program" to "/full/path/to/myProgram" instead of "myProgram", but in this case shared libraries are not found, as setup.sh would take care of that.
I have also tried to source setup.sh on a shell and then launch visual studio code from the same shell, but this did not solve the "launch: program myProgram does not exist" problem.
Do tasks run on different shells? How can I have the preLaunchTask running in the same shell as the subsequent program code? Or any other hint on how to get my workflow working?
My solution is to use a env_file
In one terminal, source your file such as: source /opt/ros/melodic/setup.bash
Recover the changes by using: printenv | grep melodic
Create a .env file in your repo with the environment variables; (except PWD)
LD_LIBRARY_PATH=/opt/ros/melodic/lib
ROS_ETC_DIR=/opt/ros/melodic/etc/ros
CMAKE_PREFIX_PATH=/opt/ros/melodic
ROS_ROOT=/opt/ros/melodic/share/ros
PYTHONPATH=/opt/ros/melodic/lib/python2.7/dist-packages
ROS_PACKAGE_PATH=/opt/ros/melodic/share
PATH=/opt/ros/melodic/bin:/home/alexis/.nvm/versions/node/v8.16.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PKG_CONFIG_PATH=/opt/ros/melodic/lib/pkgconfig
ROS_DISTRO=melodic
Add the following line to your launch.json task: "envFile": "${workspaceFolder}/.env"
Note: this could be automated in a prerunTask using:
command: "source /opt/ros/melodic/setup.bash; printenv | grep melodic > ${workspaceFolder}/.env"
Perhaps this might help after a zoom.
Got that info from here

Codelite issue--No executable specified,use 'target exec

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

GDB on eclipse debug mode can't find stdlib/rand.c

I am trying to put the gdb to run with eclipse cdt on ubuntu to start debugging some simple programs. So I did the steps I reckon as necessary to get it running:
1. Create an executable project
2. Compile
3. Run
4. Create the file .gdbinit and place it on the main project folder
5. Set some of the debugger configuration:
5. I also tried to find a .gdbinit file that would look some like this:
set schedule-multiple
dir ~/gcc_build/4.7.2/build/gcc
dir ~/gcc_build/4.7.2/gcc
dir ~/gcc_build/4.7.2/gcc/cp
dir ~/gcc_build/4.7.2/gcc/lto
source ~/gcc_build/4.7.2/build/gcc/gdbinit.in
But I didn't find anything similar in my computer, even after doing a:
# find / -name .gdbinit
So, my file .gdbinit end up with the simple content - yes only that:
set new-console on
Then I clicked on Apply and Debug:
The gdb starts working nicely as expected. I press the button "step over / F6" and the debugger goes jumping through the code step by step. Until the point it reaches the command rand() and the gdb hangs with the message:
Can't find a source file at "/build/buildd/eglibc-2.19/stdlib/rand.c"
Locate the file or edit the source lookup path to include its location.
Thus I also tried unsuccessfully to find the rand.c to update this path to include its location:
# find / -name rand.c
# find / -name stdlib
After the error message from GDB complaining that rand.c is missing, then I tried to keep stepping... since then the stepping mode is disable when I restart the debug:
Is this problem happening because some setting for my file .gdbinit is missing? Or some how GDB is not able to find the rand.c from stdlib from c99? When I compile and run the program it runs nicely. Only when I try to launch the debugger is when GDB crashes.
Update: I got the missing rand.c problem after running the commands:
# apt-get install libc6-dbg
# apt-get source libc6
But now a different error appears:
Can't find a source file at "/build/buildd/eglibc-2.19/csu/libc-start.c"
Locate the file or edit the source lookup path to include its location.
Should I also install that library for gdb?
All suggestions are highly appreciated.
From what I saw on your description... looking to the 4th and 5th image you posted, you did right all the required steps.
However, it seems to me that your GDB is attached to several projects. That means that unless you really need that, I would strongly advise you to select all project that you are not currently debugging and delete them from the debugger mode. So, my suggestion is that after you have done all the steps you did so far, then go on:
Debug Configurations > C/C++ Applications: (drop down it)
... then click on each project you are not compiling, with right button from the mouse select "delete" - but don't worry, it will not delete your project, but only the attachment of that project to your debugger mode.
Then restart the eclipse. When you again try to run in the debugger mode, everything will run much smoother than before.
Step1:
Go to https://www.gnu.org/software/libc/ to download glibc.
Step2:
unzip it locally and whenever the eclipse prompts "Can't find ... xxx.c", just load the file into eclipse. It will work.

Need GLIBC debug information from rpmbuild of updated source

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.

I can't debug in Code::Blocks

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.