OSX Eclipse CDT stalls at the start of debugging: "Configuring GDB" - c

I have installed Eclipse CDT and GDB.
I created a simple "Hello World" C project.
When I try to debug the project, GDB starts to behave very chaotic: I am able to debug a few times, step through the code, etc., but then it starts stalling at the begining of the next debug session with the message "Configuring GDB".
After I restart Eclipse CDT sometimes I still cannot debug, and sometimes I can, but also just for a few times, and then again the same problem comes up: stalls with "Configuring GDB" message.
I have tried hard to find the pattern, but failed.
What could be the reason for such a chaotic behaviour?
p.s.
I forgot to mention that I did sign the /usr/local/bin/gdb executable (and verified it with codesign --verify --verbose gdb).
Edit:
The screenshot shows the 2 stuck sessions:

Related

Can't launch debug - C in VS code on Linux

Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.

Building and debugging ARMV8 assembler applications on Windows

I'm trying to learn ARMV8 assembler, and am trying to build a test application on Windows. I've installed ARM DS-5 Community Edition, version 5.26.2. After much hair pulling trying to install toolchains, I finally installed the "mingw32" toolchain here: here. This seems to work - I am now able to compile and link my application (which consists of a single c file and a .s assembly file. The target created is a ".axf" file.
But I am unable to debug. I have my debugger set to "\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gdb.exe", out of the directory where I downloaded the toolchain. gdb starts up, but I get the error below:
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".
Any suggestions? Frankly, I don't really know what I'm doing here. I'm not sure I set up the toolchain properly. The problem is I can't find any documentation on how to do this in windows.
Thanks in advance!

Eclipse - "Launching 'KeyInPlaintext' Debug has encountered a problem. Error starting process."

I am currently attempting to compile and run a C program in eclipse. The problem is, every time I attempt to run a program, the same error shows up.
The image shows the error that is displayed. I am not sure what to get out of that error.
I currently have cygwin installed, and am able to run gcc and g++ on the command prompt. I also have PE Windows Parser and Cygwin PE parser enabled under Binary Parsers. I have also cleaned and built the project many times over.

Eclipse CDT Debug not in executable format: File format not recognized after strawberry installation

Maybe I'm missing something obvious since I searched the internet for quite a while but could not find a solution for the following problem:
I'm using Eclipse Kepler SP2 (Build id: 20140224-0627) with CDT and MinGW as compiler backend. Debugging C code with gdb worked great up until today (at least I noticed the problem today).
Now I get the following error message when i want to start a progam in the debugger:
Error in final launch sequence
Failed to execute MI command:
-file-exec-and-symbols C:/[...]/Debug/test.exe
Error message from debugger back end:
"C:\[...]\Debug\test.exe": not in executable format: File format not recognized
The program runs nicely and so I thought I might have screwed up some settings. But when I tried to debug an old program, everything worked until I recomplied the old program -> same problem. If I ask the C-wizard to create a new "Hello World" ANSI C application with MinGW, the same problem occurs.
The compile commands which were used are
gcc -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\test.o" "..\\src\\test.c"
gcc -o test.exe "src\\test.o"
I did not update my MinGW in between, but updated Eclipse.
Do you have any pointers on where to look for the problem?
Edit: I just checked the binary type: My old projects are all [x86/le], the newly compiled ones are [amd64/le]. This should be a trace.... Will update posting according to progress.
Edit2: argh I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
I'll post this as answer, too. Heading and tags have been updated to point to this issue more directly.
I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
BTW: This happened, because strawberry added c:\strawberry\c to the PATH in front of my custom c:\MinGW and eclipse adds those to the BUILD SYSTEM variables.
It should be a parser problem, what is your binary parser under Project/Properties/Build/Settings ?
Check Project->Properties ->C/C++ Build ->environment and path for MINGW_HOME
make sure you have right gdb version (by checking under debug Configuration ->environment).

Error while launching gdb version Eclipse

Here is an issue I've worked around by simply not using Eclipse for debugging, but it's getting out-of-hand.
I've used Eclipse Helios, Juno and Kepler over the last year and they all display exactly the same problem when I try to debug a local C/C++ application.
When I try to debug, it simply reports the error "Error while launching gdb --version".
gdb is in my path, but to be sure, I change the Debug settings to list the path explicitly. If I do that, I simply get "Error while launching /usr/bin/gdb --version", which is no better.
I'm using Scientific Linux version 6.4 (as required by my customers) and currently, I'm trying to use Eclipse Kepler. Running from the command line, gdb has no problem reporting it's version:
# gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
[... licensing info]
Please, please let me know how to fix this as I have spent weeks working at only a fraction of the rate I would expect because I'm not utilizing an integrated development environment, but using separate tools.
I've seen other similar posts, but they are either
(a) about Windows / MingW - although I've tried their ideas anyway, just in case they work.
(b) don't have any answer provided.
As Scientific Linux is a RedHat derivative, I expect RHEL or CentOS information would be as relevant for me.

Resources