Qt creator throws an error every time I want to start debugging. Here is the error:
ptrace: Operation not permitted.
Could not attach to the process. Make sure no other debugger traces this process.
Check the settings of
/proc/sys/kernel/yama/ptrace_scope
For more details, see /etc/sysctl.d/10-ptrace.conf
I have googled the error message and got some result about bug in the kernel but I am able to run gdb in command line, so I don't think it is kernel/gdb related.
What can be the cause of this error?
I just did some research and found the solution somewhere. It turns out that /proc/sys/kernel/yama/ptrace_scope was set to 1. After I changed it to 0, the problem disappeared.
Explanations of ptrace can be found here and here, as Merlin069 said.
Related
In C++Builder 10.3.3, when running my application, it stops the process and pops up with an error:
Unable to create process: Access denied
I don't know why this happens, and for the life of me I can't figure out what it is talking about.
I tried to build the solution to see if the error was occurring there, and it appears this is the case. After building the solution, the compiler stops the process and a fatal error pops up:
[ilink32 Error] Fatal: Could not open.\Win32\Debug\TabbedApplication.exe (program still running?)
Does anyone know what this error means, and how to fix it?
I added a new target platform in my project in the right
I added windows 64 bit and it worked
hope it helps
I've been getting this messages for months (even with previous verions of RAD studio) and i haven't found a solution yet.
I have used a process explorer and the process is not running but if i close and reopen the IDE the file is not locked anymore.
So i think the problem it's related with the "debugger" that stills is locking the file even when the IDE stopped the debugging process.
I have tried even the "unlocker" utility but it doesn't detect any process is locking the file ...
For know we have to wait until the debugger release the file.
These is the configuration i have tried in the registry:
HKCU\Software\Embarcadero\BDS\20.0\Debugging\Embarcadero Debuggers\Evaluators
[dedfault] REG_SZ dcc32260.dll
com32x.dll REG_SZ -1
dcc32260.dll REG_SZ 0
I am trying to build LLVM on windows, and everytime I do so I get to a certain point and then recieve an error that says "not.exe has stopped working" It pops up on the desktop about 15 times.
I am not sure what is going on, but when I check the error in Visual Studio I receive this:
Error 4 error : Couldn't execute program 'C:/Users/Cyborg/Documents/Developer'The process cannot access the file because it is being used by another process. C:\Users\Joe\Documents\Dev\llvm\test\CUSTOMBUILD check-llvm
I receive this error 5-7 times depending on how fast I click the error that pops up on the desktop. So clearly this issue is happening because of that.
The fault module is: MSVCR100.dll
Does anyone know why this is happening?
I don't know why you're getting the error since I don't build or use LLVM on Windows. Since no one else has chimed in, I'll try to give a hint or two.
"not.exe" (or "not" under Linux) is a little LLVM helper program used when running the lit based regressions tests. It is used to execute a program and return a good exit status if the program fails and a bad exit status if the program doesn't fail.
I'm guessing that "CUSTOMBUILD check-llvm" (what ever that is) is attempting to run the regression tests and your getting your mysterious error as a result whenevr "not" is used.
I hope that helps.
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.
I'm trying to compile my C++ program, but when I press the "Build" button, it displays the following error message:
c:/gnat/2010/bin/../libexec/gcc/i686-pc-mingw32/4.3.6/ld.exe:
cannot open output file a.exe: Invalid
argument collect2: ld returned 1 exit
status
This is not the first time it has done this. It seems to do this most when I have been editing the same project a lot and building it often, almost as if something has been flooded, or overloaded, or something.
I had fixed it before, I believe, by restarting my PC, but I can't afford to keep restarting my PC every time this occurs.
I thought this was just a one-time problem, but it has continued to happen and so I thought I'd look for more help on this.
I found another SO question that I thought had the same error message/problem as I had. However, when I tried the solutions listed on afore-linked question, nothing helped.
Has anyone else had this issue? Or does anyone know how I can fix this issue (besides restarting my computer every time)?
I am developing in jGrasp also, if that helps any.
EDIT: I just wanted to add that I thought it might be that my previous executable was still running in the background, but even if I close my IDE, it still won't let me delete the executable, because it says it is still running.
I checked my process explorer to see if the a.exe was still running, but there's absolutely nothing in my processes that has to do with jGrasp or a.exe
I guess your executable is still running. It's the only reason I think about... I guess the best is to check on your task manager (process Explorer is your friend ;)).
In Visual Studio Code, go to Settings -> Search for "clear previous" in the search bar and check on the box named "clear previous output". :)
It is happening because your previous output is already running in the background. And VS Code offers a feature to close that on every run.
EDIT: it's nothing to do with collect2.exe.
Do you get any other error text, like for example 'permission denied errors' etc.
http://max.berger.name/howto/cdt/ar01s05.jsp
It is beacause the .exe is still running. If you're on Windows use the command line del -f a.exe and if you're on linux use rm -rf ./a.out
I have the same problem, was worried for hours. I disabled my avg antivirus and it worked.
I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.