I'm having remote ARM Linux box which I need to debug.
The server is started:
gdbserver :12345 ./my_app
The client:
./arm-am3354-linux-gnueabihf-gdb ~/
(gdb) target remote dev_r:12345
(gdb) continue
Then I'm trying to pause the app with Ctrl+C, but the gdb stops with:
[Inferior 1 (process 2766) exited with code 01]
And on server:
Child exited with status 1
GDBserver exiting
Story:
I was trying to use remote debugging in QtCreator, but when setting breakpoints in run-time the gdb was crashing in the same way. Also the breakpoints and pause is not working in QtCreator.
I was trying also another gdb like gdb-multiarch and the one from android-sdk.
Update:
Debugging small program aka Hello World works. Local Debugging (on x86) works too. The app itself has hundred thousand lines of code, shared and static libraries.
Partial solution:
Probably the sysroot for embedded platform that I've got was invalid. After copying /lib/ and /usr/ from the target device and setting it as
set sysroot /home/karel/sysroot
I'm able to set breakpoints and the app stops at them. The pause however is still stopping the remote app. The same for QtCreator: Tools->Options->Debugger->GDB->Additional Attach Commands
I had a similar (or even exactly the same?) issue with debugging my application running on the EGLFS platform. Debugging when built with Qt 5.4 was working perfectly fine, debugging with Qt 5.5 did behave as you describe.
After hours of searching, I found that my application on Qt 5.5 exited when receiving a SIGINT, whereas on Qt 5.4, the debugger could pause the application as expected. Since GDB sends SIGINT when trying to pause the application or setting / removing a breakpoint, this was where trouble started.
After some more research, I finally found the following commit to Qt 5.5: Fix up signal handling in QFbVtHandler. At the very end, you see that when receiving SIGINT or SIGTERM, the handleInt() handler is called where we finally run into _exit(1). Setting a breakpoint there confirmed that this is exactly what happens when trying to pause or set a breakpoint with GDB.
Solution that worked for me: I have created a patch to qfbvthandler.cpp, simply removing the #define VTH_ENABLED line.
GDB debugging is now again working like a charm.
Note: Even though qfbvthandler.cpp has been updated in Qt5.6 and upwards, I suspect the behaviour would still be the same. I however don't have a workspace set up in order to test this.
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.
Recently, Eclipse SDK decided to kill my brain cells.
Out of the blue, it just stopped pausing at breakpoints. I do see it hit the breakpoint, but right then window loses focus and in the thread/callstack window it shows
MyApp [C/C++ Application]
MyApp [18556][cores:1]
Thread [2] (Running : Container)
Thread [1] (Running : User Request)
gdb
I see when i hits my breakpoint and it takes a blink of an eye before it goes into above state. My app stops responding and working and i have to kill it.
My app is a non GUI application which runs in linux as a background task, it reads and writes files, performs communication through COM and TCP/UDP. No user input is ever requested or anything like that.
There are tons of people who have problems with eclipse having problems with breakpoints, however they all are about java projects and or windows version of eclipse and none of the provided solutions work for me.
So far i have:
Rebuilt index.
Cleaned and rebuild project.
Deleted all debug files, makefile, binary and built again.
Cleared all breakpoints.
Made sure it was not set to ignore breakpoints.
and probably more which i already forgot.
Eclipse version is 4.2.1
Linux: Arch linux which was not updated for like 2 years now.
Project is C++.
What other information do i need to provide?
How can i solve this problem. I can't debug my application :(
I resolved this problem in this way: "Run" -> "Debug Configuration" -> select you configuration -> Debugger.
Then check the checkbox which shows "Use external console for inferior (open a new console window for input/output)".
In a simple Hello World Project in Eclipse CDT (version: Kepler) on Windows 7, I tried to set breakpoints to debug the program.
However, when the program is launched, the debugger stops at the first line of main(), and when the Resume button is pressed, all the breakpoints are skipped and the program terminates with: expect signal SIGINT when the program is resumed.
A strange thing happened too: the same installation on a second computer in which the username does not include spaces works fine.
The console for gdb traces does not report anything strange. The breakpoints are set and the execution does not report other errors (but I don't assure this is the problem).
The same settings are used on MacOS X too, but here it works fine.
Any hints? Thank you.
After I step through any code in this file in particular in a static library, gdb crashes after a couple of seconds.
I can step through other parts of the static library and shared libs that I have loaded and it works fine. The program runs fine and does not crash after gdb crashes.
gdb version 7.5.91.20130417-cvs-ubuntu on linux mint 15
How do I stop gdb from crashing in qtcreator?
If GDB is crashing, that sounds like a bug in GDB, from their docs:
If the debugger gets a fatal signal, for any input whatever, that is a gdb bug.
Reliable debuggers never crash.
Which version are you running/does upgrading to a newer version help?
provided as a supplementation:
I also encounter this gdb crash with qtcreator 5.0,after upgrade to qtcreator 6.0.1 ,error still existed with
"gdb crashed unexpectedly exit"
run the qt project is ok,when debugging ,and the qtcreator hit a breakpoint ,gdb will crash in about 3 seconds.
how I fix it:
remove cached QtProject folder under current user.
find . -name QtProject
in current user directory.
and remove the folder.
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.