I have written a test fastcgi app. I want to debug it, using the Netbeans IDE. When I attempt to attach to the process, I get the error:
Gdb could not attach to the specified process.
I then tried the following:
sudo -i /bin/sh "path/to/netbeans"
Attaching to the process still failed (Got the message: Gdb could not attach to the specified process).
I then tried the suggestion made at this link
That also failed. I got the nessage: The executable associated with the selected project does not match the selected process ID.. after changing the run path so that the project executable now points to my cgi-bin directory, I now get the error: Gdb could not attach to the specified process.
I am now at a loss as to how to debug my app, using Netbeans. In case netbeans can't do this, is there another visual debugger that I can use?
I am running Linux Ubuntu.
Netbeans does have the ability to use gdb to attach to a process. From the link you posted did you also follow the "update" from the comments describing how to fix the kernel ptrace_scope issue in Ubuntu?
Another thing to try is to see if you get the same error attaching gdb via commandline, or if you really want to use a gui DDD. That way you can isolate whether it is Netbeans, gdb, or a permission problemn in Ubuntu.
Related
I am trying to remote-debug a project in Clion but I can't seem to get a working debugging session. I think I've correctly launched my gdb server/client because my gdb client connects to the JLinkGDBServerCL.exe process
and they communicate.However, in clion, I can't break in the source code. The only thing that I get from clion is a disassembly of my program with no symbol at all which is odd because there is a symbol table in the .elf
that I am trying to debug. And one last detail, I can't "step in" the assembly code neither (but I can run commands in the gdb client in Clion).
Here is a picture of my debug configuration : debug config
And here is what I'm talking about when I say I can't get a proper debugging session : "debugging session"
Does anybody know what the problem is ?
System info:
OS: Windows 10
IDE: Clion 2018.1.6
GDB Server: JLinkGDBServerCL.exe
Target: TM4C129 (cortex M4) (no OS, just a firmware)
Program: USBMicroloader.elf (debug mode)
I'm having the same issue. I found that if I add the path to the elf file from the build directory into the "Symbol file" (in the run configuration where you set up the remote gdb connection), it fixes your issue. This seems a bit kludgey, but I haven't been able to find a better solution.
However, the next issue I run into is that I can only run that configuration a single time. When I stop debugging I get a message in the console that reads Remote doesn't know how to detach. Debugger disconnected. The clean and build menu options are greyed out until I restart CLion.
Can someone give instructions on how to run/debug an OpenMPI (C/C++/Fortran) program in Eclipse PTP using the actual parallel run/debug modes on a local machine?
I've set a local connection in the 'Remote Environments' section. If I specify the actual program executable as the executable then eclipse gets stuck with 'submit interactive' and 'Launching... Submitting the job...' in the progress window, and I'm left with the specified number of processes of the program running at full CPU indefinitely. If I specify another program, like mpirun or mpiexec, and provide the necessary arguments to get to the program executable then the only difference is that I have the same number of mpirun's running at 0 CPU.
I should add that if I actually select "Local" under "Connection Type" then I get an error:
Failed to execute command: ompi_info -a --parseable
Reason: Cannot run program "ompi_info": Unknown reason
even though that command works fine from the command line and runs successfully when connecting to local host as setup in the 'remote environments'
I've seen the guides on the Eclipse website, but they're no help. I've checked [1] and [2], but I still get this working right.
I can get a program running successfully in parallel by treating it like a normal program and setting the executable to mpiexec and providing the necessary arguments, but I want to do actual parallel debugging, so this doesn't suffice.
EDIT:
I should be more specific. I know there are other methods of debugging, but Eclipse PTP (parallel tools platform) should be able to handle this perfectly, so I'm looking for an explanation from someone who has setup Eclipse PTP on their local machine such that they can use a parallel run configuration and the parallel debugging tools.
Please ask your question on the ptp-user mailing list.
https://dev.eclipse.org/mailman/listinfo/ptp-user
Sounds like openmpi isn't in the path available within eclipse
In fact, this is in the PTP FAQ on https://wiki.eclipse.org/Parallel_Tools_Platform_FAQ#Q:_I_get_the_error_.22Failed_to_execute_command:_ompi_info_-a_--parseable.22_when_I_use_the_Open_MPI_target_configuration_on_my_Mac
I've never actually used the Eclipse IDE, but I debug my MPI code using xterm and gdb:
mpirun -np 2 xterm -e gdb -ex run ./tool
Not exactly what you where after, but perhaps it helps...
Not sure which OS you're using, but I had this issue on MacOS. It's because Eclipse doesn't run .bash_profile or .bashrc, so its environment (namely PATH) won't have everything it needs. You could try to edit the PATH variable to include it by some other means (which I found to be overly complicated on Mac), OR you can just run the eclipse executable from a shell so that it inherits your typical environment. For me this was located at:
~/eclipse/parallel-neon/Eclipse.app/Contents/MacOS/eclipse
Then eclipse was able to detect OpenMPI just fine (PATH contained /usr/local/bin).
I'm running Eclipse on win7. I want to make console applications that can run on either windows or linux. I followed the guide here on how to setup the compiler
I'm trying to compile and run a simple hello world program. It compiles fine, but when I try to debug I get the following error:
'launching test' has encountered a problem.
Error in final launch sequence.
Clicking details reveals the following information.
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don't know how to run. Try "help target".
Don't know how to run. Try "help target".
My gdb debugger path is C:\codesourcery\bin\arm-none-eabi-gdb.exe
I'm not exactly sure how to proceed.
If you're creating a windows console then I would think you would need gdb found in c:\minGW or wherever you have your Windows 7 gcc toolchain.
To change your debugger on Eclipse Kepler go to:
Run->Debug Configurations. Select Debugger tab and in the "GDB debugger:" field, enter the path of your Windows gdb.exe file (c:\MinGW\bin\gdb.exe if you're using minGW)
I realize this is an old question, but hoping it will help someone. In my case, there was a breakpoint set with only a memory address (no file name associated with it). Not sure how I got into this situation... Once I removed the breakpoint, I was able to launch my program with debugger. Note, I am using Eclipse Luna CDT (SR2)
I've just spent a whole day trying to find a way to enable GDB debugging from Qt Creator or Eclipse. I learned that there are basically two approaches to launch the target application:
Using ssh (ssh host gdb)
Using gdbserver
I was able to use both approaches to launch gdb remotely and start the application. However, GDB never responds to any breakpoints set in the IDE. Also I can't pause the application to inspect the program state. In Qt Creator I just get an obscure stack trace (I might have been looking at the traces of ssh or gdb actually...).
Can anyone help me to get started?
Progress!
I found that with Qt Creator 2.0 there is an feature called "Attach and debug remote application." It's based on gdbserver. The good thing is that it stops on the IDE's breakpoints. However, there are two issues:
When it hits a breakpoint it only shows assembly code, not the source code.
GDB often quits because of 'signal received'
I should probably mention that the remote executable is compiled with an older version of GCC than the one installed on my local PC. Perhaps some of the problems are related to this.
Update
I should mention that I switched to running cgdb on the remote machine via SSH.
The remote Qt Creator-based solution wasn't stable. GDB tends to quit because of mysterious 'signal received' messages.
So that GDB on your host (the machine you develop and compile on, so where you have Qt Creator) you have to give it access to the "symbol file".
I usually don't use Qt Creator, but GDB and gdbserver directly for cross-compiled programs remote-debugging. You could maybe give this a try to be sure that this works for you and maybe then find the missing option in Qt Creator (or maybe this will help you find what is missing).
On the target machine run:
gdbserver :5000 yourprogram
On the host machine, run gdb and then load the symbol file:
(gdb) symbol-file yourprogram
On GDB on the host machine, you then have to connect to connect GDB to the remote gdbserver:
(gdb) target remote target_ip_address:5000
From then you can use GDB on the host controlling the program on the target.
I hope this helps!
Due to peculiarities in our makefile build system the file references contained in the debugging symbols look like this:
../src/main.cpp
../../src/utils/logger.cpp
This is no problem for GDB, but Qt Creator was unable to map these paths to the actual files. I was able to fix this by adding 'dir' statements in the GDB init file:
dir src
dir src/utils
...
Now it works.
We're using the Eclipse CDT 5 C++ IDE on Windows to develop a C++ application on a remote AIX host.
Eclipse CDT has the ability to perform remote debugging using gdbserver. Unfortunately, gdbserver is not supported on AIX.
Is anyone familiar with a way to debug remotely using Eclipse CDT without gdbserver? Perhaps using an SSH shell connection to gdb?
finally I got gdb run remotly anyhow now. At the Bug-symbol on the taskbar I took Debug Configurations - GDB Hardware Debugging.
In Main C/C++ Applications I set the full path on the Samba share of the executable (X:\abin\vlmi9506). I also set a linked folder on X:\abin in the project. Then I modified my batch-script in GDB Setup. It's not directly calling gdb in the plink-session but a unix-shell-script, which opens gdb. By this I have the possibility to set some unix environment-variables for the program before doing debug. The call in my batch:
plink.exe prevoax1 -l suttera -pw XXXXX -i /proj/user/dev/suttera/vl/9506/test/vlmi9506ddd.run 20155 dev o m
In the unix script I started gdb with the command line params from eclipse, that I found in my former tryals. The call in the shell command looks like this:
gdb -nw -i mi -cd=$LVarPathExec $LVarPathExec/vlmi9506
Then IBM just gives gdb 6.0 for AIX. I found version 6.8 in the net at http://www.perzl.org/aix/index.php?n=Main.Gdb. Our Admin installed it.
I can now step through the program and watch variables. I even can write gdb-commands directly in the console-view. yabadabadooooooo
Hope that helps to others as well. Can not tell, what was really the winner-action.
But each answer gives more new questions. Now I got 3 of them.
When I start the debug config I have to click restart in the toolbar to come really in the main procedure. Is it possible to come directly in main without restarting?
On AIX our programs are first preprocessed for embedded sql. The preprocessed c-source is put in another directory. When I duble-click the line to set a breakpoint, I get the warning "unresolved breakpoint" and in the gdb-console I see, that the break is set to the preprocessed source which is wrong. Is it possible to set the breakpoints on the right source?
We are using CICS on AIX. With the xldb-Debugger and the CDCN-command of CICS we manage that debugging is started, when we come in our programs. Is it possible to get that remotely (in plink) with gdb-eclipse as well?
I wouldn't normally take a shot in the dark on a question I can't really test the answer to, but since this one has sat around for a day, I'll give it a shot. It seems from looking at:
http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F
...that even if the CDT has changed since that wiki page was made, you should still be able to change the debug command to:
ssh remotehost gdb
instead of using TM which uses gdbserver. This will probably be slightly slower than the TM remote debugging since that actually uses a local gdb, but on the other hand this way you won't have to NFS or SMB mount your source code to make it available to the local debugger (and if you're on a LAN it probably won't matter anyhow).
There's also a reference TCF implementation for linux, which you may or may not have any luck recompiling for AIX, but it allows for remote debugging if gdbserver is otherwise not available:
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ
tried also to remotly debug an aix-appl with windows eclipse-cdt-gdb.
Got blocked at the end with unix/windows path-problems. Maybe my result can help u a little further - maybe you already got it work. I'm interested in your comment. asked on eclipse news portal- following the answer of martin oberhuber (thanks again) tried dsp dd (also blocked with path problem) and set an request in eclipse bugzilla.
here the link to news:
http://www.eclipse.org/newsportal/article.php?id=406&group=eclipse.dsdp.tm
Here my bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252758
At the moment we still debug localy with xldb but I am trying ddd-gdb at the moment. At least locally gdb is running.