I'm having a problem debugging a command line program on OS X. I've used this same source file with the same g++ command line hundreds of times to test things with the Crypto++ library.
Under GDB, I get the following after loading the EXE:
$ gdb ./cryptopp-test.exe
...
(gdb) r
Starting program: /Users/jwalton/cryptopp-test.exe
Unable to find Mach task port for process-id 42811: (os/kern) failure (0x5).
Under LLDB, I get the following:
$ lldb ./cryptopp-test.exe
Current executable set to './cryptopp-test.exe' (x86_64).
(lldb) r
error: initial process state wasn't stopped: exited
I've recompiled the program a few times, and I can't get it to run under a debugger. I'm getting a segfault when trying to run outside the debugger too, so that may be a symptom here also.
OS X is 10.8.5, and Xcode is 5.1.1 (5B1008). Everything is fully patched. The only thing to change recently is signing up for a developer account, which is broken thanks to Apple's DRM crap. I can't seem to get any of it to work with Xcode or the command line even though Roots and Certificates are in my Keychain. But this program does not use code signing.
What is causing the initial process state wasn't stopped: exited error, and how do I fix it?
The errors that you have received are usually a direct correlation of a codesigning issue, not with your executable, but with gdb and lldb themselves.
You have a couple of options:
Launch gdb or lldb as sudo (which ignores the codesign req to run executables)
Create a codesigning certificate for gdb or lldb in Keychain.app
Obviously the first option is quickest, but probably should be avoided as it opens up the possibility of bad things happening with elevated permissions.
With option #2 you can likely get gdb or lldb properly working by doing this:
Launch /Applications/Utilities/Keychain Access.app
Select the Keychain Access -> Certificate Assistant -> Create a Certificate...
Choose a name for the new certificate (for example lldb-cert or gdb-cert)
Set Identity Type to Self Signed Root
Set Certificate Type to Code Signing
Select the Let me override defaults option
Continue until the "Specify a Location For The Certificate" screen appears
Set Keychain to System and Continue
In the view showing your certificates, double-click on the one just created and then set "When using this certificate" to "Always Trust"
In Terminal:
codesign -f -s "gdb-cert" /path/to/gdb (or) "lldb-cert" /path/to/lldb
You might have to restart for this to effectively take hold.
There are more concise instructions here for gdb and here for lldb on the codesigning process.
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I'm trying out STM32CubeIDE, and I've been trying to get it to work with the GDB QEMU debugging plugin that's part of the Eclipse CDT package. I've been able to create the project and debug configuration for my STM32F4-Discovery board, and the debugger partially launches, however, just as the simulator starts up, the GUI window it creates suddenly crashes and I get this error:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Truncated register 18 in remote 'g' packet
I think this is caused by some mismatch between the CDT plugin I installed and the GCC toolchain that shipped with my installation of Ubuntu 20.04. However, I'm not sure how to fix this.
Is there anything I try to fix this?
So it looks like there were a couple factors as to why this wasn't working. First off, the error messages that I was getting immediately after the GUI debugger terminated were due to an incorrect installation of the arm-none-eabi-gdb package. In order to fix this, I downloaded the package from the ARM site and followed the instructions detailed here. After installing the arm-none-eabi-gdb package again, I went into the project debug configuration settings, navigated to the "debugger" tab in this window, and then changed the GDB executable path from the variables the IDE had set for me to the actual GDB executable path (in this case /usr/bin/arm-none-eabi-gdb).
After that was done, the debugger would no longer immediately terminate, but I was still getting some errors in console shortly after it started (see below). In addition, the debugger GUI would produce no meaningful output, and Ubuntu would warn that the process had frozen.
NVIC: Bad read offset 0xd88
qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.
To solve this, I right clicked the project in the project explorer panel of the IDE, then went to C/C++ build section, then to the Settings section under that, and then finally to the "Tool settings" section of this menu. Under "MCU settings", there are two options for "Floating point unit" and "Floating point ABI", which I changed to "None" and "Software implementation" respectively. After saving these configuration changes, I went to the system_stm32f4xx.c file under the src/ directory of the project, and commented out these lines:
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif
After that, I cleaned the project, rebuilt it, and relaunched the debugger. It then functioned normally.
I have a setup with openocd and arm-none-eabi-gdb and I'm trying to debug a FreeRTOS fw.
I start openocd with:
openocd -f /usr/local/share/openocd/scripts/board/stm32f0discovery.cfg -c "stm32f0x.cpu configure -rtos auto"
That command works fine.
Then I run arm-none-eabi-gdb -tui and at the end of my .gdbinit I have:
target remote localhost:3333
monitor reset halt
file build/fw.elf
load
continue
focus next
But when I try to stop <ctrl>-c and start continue my fw all I get is the error:
Cannot execute this command without a live selected thread.
What am I missing?
I'm using a JLink Base debug probe.
My case is a bit different than yours, with a setup using QtCreator and its Baremetal plugin, but found a bug report where they state a workaround:
https://bugreports.qt.io/browse/QTCREATORBUG-18436
The workaround is pretty easy:
in GDB Init commands add "info threads" after load command. It fixes issue.
I tried it, and it worked, the error message was removed, and now I can see the different tasks in FreeRTOS.
when I run gdbserver on uclinux target device blackfin bfin537/stamp it work perfectly but it always generates annoying output
Request to get for unknown register 232
Request to get for unknown register 236
it is extremely annoying since each step out or step in gdb client results several of that error on the output screen terminal RS232 I was recommended to change the bfin compiler version and rebuild gdb server with different version of uclinux ,.... none of them worked and even compiling my code with different versions of bfin-uclinux-gcc didn't solve my problem.
I decided to recompile gdbserver.c and eliminate the line that generates the error but in fact that line does not exists in any of the gdbserver related files for compiling.
I decided to suppress the stderr output of gdb server by running gdbserver :3298 process 1>/dev/null 2>/dev/null but this didn't solve it
how can I configure my gdb client to asks for specific registers (bfin-uclinux-gdb) related to bfin537-stamp?
I think this error originates somewhere else in uclinux system background system processes.
I want to find which process writes in stderr,stdout which I am unaware of It and I want to suppress its outputs?
Shall I change something in the busybox shell or /bin/bash to eliminates all stderr outputs
which means if I send all the parent shell output or stderr to /dev/null
Thanks
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.