This has been working fine for a while, and there are lots of eclipse breakpoint bugs, but this one's not like the others.
I can add a breakpoint, it shows up in the breakpoint list but as soon as I make the breakpoint, the little blue dot with the checkpoint shows up, then the checkpoint goes away.
Here's the gdb trace...
355,448 50-break-insert -f xxx
355,448 50^done,bkpt={number="9",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000435f1e"\
,func="xxx(void const*, unsigned long)",file="xxx.cpp",fullname="xxx.cpp",line="223",thread-groups=["i1"]\
,times="0",original-location="xxx.cpp:223"}
355,448 (gdb)
... and then this happens....
355,601 51-break-delete 9
355,601 51^done
355,601 (gdb)
I'm sure it's some state bug of some config somewhere, and I don't really care why. I have deleted all my breakpoints and restarted,
where is the debugger related cache stuff stored so I can try and delete it?
I'd rather not have to rebuild my workspace.
EDIT:
my gdb version is
GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10
eclipse version...
Eclipse IDE for C/C++ Developers
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600
cdt...
Eclipse C/C++ Development Tools
Version: 8.6.0.201502131403
Build id: #build#
I copied this eclipse setup from a machine
with this version of gdb and it was working fine.
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
(There was an earlier answer with some of this information, now deleted?)
With CDT 8.6 there is a known bug that is now fixed. The gist was there was a race condition that now has been resolved in CDT 8.7 (Eclipse Mars).
For the ongoing issue OP raised bug 19503 against GDB. Based in part on the information there it seems that potentially turning off debug forked processes may aleviate the situation in Eclipse. In the launch configuration, uncheck the "Automatically debug forked processes", the last of the options marked below:
Related
I am using
Eclipse IDE for C/C++ Developers
Version: 2018-09 (4.9.0)
Build id: 20180917-1800
under Win 10 with Portable Msys2, and gcc 8.3.0.
When launching a debug configuration in CDT, I am getting message
Error in final launch sequence: Command '-file-exec-and-symbols myprog.exe' is timed out
Session is terminated
Reason: Commnd '-gdb-exit' is timed out
Note: I only get this error while trying to debug one project.
All my other debug configurations for other projects run with no problem.
I have copied one of these working debug configurations and changed only the project name and executable into the problematic one, and I still get the error.
One possible solution I found is (here and here) downgrading component
C/C++ GDB Hardware Debugging (Help -> About Eclipse IDE -> Installation Details -> C/C++ GDB Hardware Debugging)
from 9.4.0.201712051550 to 9.3.2.201709131603.
I have
Version 9.5.3.201809121146 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT.
Perhaps in my case downgarding to that old version would work too.
Prior to messing up with the downgrading, I meant to try another option (here and here):
In the debug configuration of the project, in the debugger tab, uncheck
“Reset and Delay (seconds)” and
“Halt”.
(more details here)
But I couldn't find these settings in the Debugger tab, and I do not have the Startup tab under either the Debug configuration for my project or GDB Hardware Debugging, as shown here or here.
See image.
Where can I find these settings?
Are there any other alternatives to try solving the issue, other than these two? (lest reinstalling, e.g.)
I am looking for something that allows me to debug my project, so far I cannot.
References I found for similar topics (although not exactly the same) are:
Error in Final Launch Sequence - Eclipse System Workbench Debugging for STM32L476
http://www.openstm32.org/forumthread6323
I had good times debugging Java applications on Eclipse, but recently that I'm working on a C/C++ on Ubuntu 12.04 using Eclipse CDT, it ignores the breakpoints when debugging! I've tried two versions of Eclipse CDT, CDT 8.4.0 for Eclipse Luna, but doesn't work either. Can somebody help with that?
NOTE: I know there are some other similar questions, but I was thinking it is better to ask this question which specifically addresses CDT 8.4.0 for Eclipse Luna.
The eclipse-cdt is shipped only with the required tools for building c/c++ applications. It does not ship with gdb. You need to install that separately
How do I use GDB in Eclipse for C/C++ Debugging?
From link above these are the steps to follow.
1. Go to Help > Install New Software.
2. Add the CDT repository http://download.eclipse.org/tools/cdt/releases/8.4 to the list of repositories.
3. Select the CDT Repository. Now you need to install the CDT plugin along with GDB support from the list of available plugins (Select the CDT Main Features as well as CDT GNU Toolchain Debug support).
I updated the CDT repository path to correspond to your release (Luna).
It also happens for me in ReadHat 64
Seems like if the CDT breakpoints are not suitable for the current debug session, in the breakpoint window, when enabling "Show breakpoints Supported by selected target" all my breakpoints disapears from the list.
In my case, my ELF have debug info and all the breakpoints that I place are in the main ELF.
My debug settings worked fine with the former Eclipse version.
I rolled back to eclipse Juno, and my debug session with same elfs worked out of the box.
Experiencing the same problem here.. I am working around it by manually setting breakpoints after starting debug session. Console -> gdb, then type "break xxxx".
If you're using MinGW gdb, check that C:\MinGW\bin is in your path (set in System Properties). Made all the difference for me.
I once had Skip All Breakpoints accidentally checked, and was wondering what was going on.
I have the same problem with my eclipse Photon, I figured it out by unchecking the
"stop on startup at: main" in Debug Configuration-->Debugger.
I know this in Rikard Söderström's response to you.
On Linux, I have some C++ programs built with my own makefiles, and I'm looking for some GUI debuggers to debug them at source level.
Previously I use KDbg(2.5.2) on openSUSE(12.3). It works but with some very annoying limitation, e.g., I cannot set a breakpoint when the debugged program is not trapped by Kdbg -- I mean, in order to set a new breakpoint, I have to set it before the program is launched or the program pauses on hitting an already set breakpoint.
Now I try to use Eclipse CDT. I got eclipse-cpp-juno-SR2-linux-gtk.tar.gz but find that I don't know how to load my executable so to start debugging.
I googled with words like 『eclipse debug pre-built C binary』, but few seems to care about this feature.
Can Eclipse CDT really do that? If Eclipse CDT can't, is there any better alternatives to KDbg? Please help.
According to hint from this answer, https://stackoverflow.com/a/248119/151453 , I finally figure out how to do it.
The key point is: In the Eclipse CDT project, create/edit a Launch Configuration so to tell the debugger what executable to load.
Now I have to admit, Eclipse CDT does quite well in C++ code debugging far better than KDbg.
Some screen shot below, on openSUSE 12.3 .
Now we can Run -> Debug (F11)
Debugger automatically pauses the program at main()'s first statement.
The Stand-alone Debugger is an Eclipse application which packages the Eclipse plug-ins from the CDT (C/C++ Development Tools) project into an application that can be started from a command-line script:
bash /path/scripts/cdtdebug.sh -e executable [args]
I've got a problem with gdb debugger. My console app shows me incorrect action results (some trash instead of normal string which I've got from XML ater the parsing) if I run it under a debugger plus I get SIGINT ( I don't output eol character and don't hit ctrl+c). Running my app with no attached debugger (just double click on .exe or Run menu from IDE) shows me correct results. What is the problem?
Some Info:
Windows 7 Pro Sp1 x86
gdb 7.3.1 (MinGW) and gcc 4.6.2 (MinGW)
Eclipse 3.7.1
Here is a gdb trace.
At this screenshot you can see the settings
Probably you have some memory corruption in your application and and they become visible when you use the debugger. In order to solve the problem we need to take a look on your source code.
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.