When I try to use the debugger on a simple test project the console dumps out the following:
warning: `/var/folders/s1/dxx9glzn45j6x2ypzk9xkjnc0000gp/T/Test-0061ba.o': can't open to read symbols: No such file or directory.
$1 = 0xff
The target endianness is set automatically (currently little endian)
No symbol table is loaded. Use the "file" command.
Launching the debugger gets 99% complete and gets stuck! It just hangs there for awhile and when I try to terminate the connection nothing happens. Then when I go to shut down eclipse I usually have to force quit it :( Anyone have any ideas?
I fixed this issue by correcting the gdb-cert. Make sure you select code signing "Always trust"
Related
I am using gdb 7.7.1 on ubuntu, GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1.
My terminal is Konsole 2.13.2.
The problem I am having is, when I go to the TUI mode, after one or two debugger sessions - session, I mean, set breakpoint, run, step over a while and finally kill it by "kill" command - the output starts messed up. Supposedly each output should go to a new line, but now they just all scramble, one immediately after another one.
I attach a screenshot.
I have to quit GDB, open a new terminal tab and start gdb again.
I tried "ctrl-x-a" back and forth, does not help; neither does "ctrl-l".
A while back, I was using another terminal, it also had this problem.
Any help is appreciated.
It appears that your tty settings changed, in much the same way that tty -onlcr might change them (tty onlcr restores the default). Perhaps the code you're debugging changes tty settings, and doesn't get a chance to restore them because of a crash.
As suggested in a comment, using a separate window might provide a workaround.
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 created a simple pin tool that dumps any win32 CreateFileW calls. It works fine, but when i try to attach it to an already running process, the process simply terminates. Tried with several applications (notepad, wordpad, internet explorer), same result. This is the command i use:
.\pin -pid 8804 -t dumpfile.dll
I got a tip to try and turn off multi-threading like this:
.\pin -mt 0 -pid 8804 -t dumpfile.dll
but it did not help. Also tried with another, out of the box pintool, didn't work either, so the problem is not in my pintool. Any ideas?
Thanks in advance!
Okay, today i had some time on my hands to research this problem again. Tested with a console application launched from cmd, and before shutting down, it actually dumped an error message, the .dll (the pin tool) was not found...
So when running pin you actually have to specify the full path to your pin tool, or the path relative to the instrumentated binary's location.
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.
Hey guys,
I have written a program to act as a keyboard backlight controller for my MacBook Pro that runs Arch, just like there is natively in OS X. The program itself works great, but the rc.d script I provide with the Arch program package, doesn't seem to open the program correctly ... or so I think.
The source to the Arch package can be found here (rc.d script and PKGBUILD file). I have added "mbpkbdbacklightctl" to the line with daemons in my /etc/rc.conf.
What happens is, that upon start up, I see that the rc.d script starts the program is started without errors, and the backlight on the keyboard is lit on which means the program is also run properly, but then when gdm starts to log in to gnome, the program seems to already have been terminated. I havent been able to find any errors logged, but the program will turn off the backlight if no keyboard or mouse events are registered in 20 or more seconds and turn it back on when one it registered, and this doesnt happen at the gdm and neither in gnome. Also, when I reach gnome and do a pidof -o %PPID /usr/bin/mbpkbdbacklightctl, it returns nothing indicating that the program has been terminated. When gnome is started, I have to restart the rc.d script to make things run properly.
I cant seem to get a grasp on what happens to the program since it is terminated.
The source to the program can be found here, though, I believe that the error is in the rc.d script and that it might not start the program properly for it to "survive" through gdm start-up.
Any ideas to what can be going on?
Regards,
Chris Buchholz
If you read the source code for mbpkbdbacklightctl.cpp you will see these lines:
95 std::string the_display = ":0.0";
96 Display *x11_display = XOpenDisplay(the_display.c_str());
97 if(x11_display != NULL) {
So it will fail if there is no active X server, this means that you have to start this script after X session starts. So you have to put your script under /etc/X11/xinit/xinitrc.d