On Windows 7 I have Eclipse Neon (4.6.3) with Liclipse/PyDev, and I am using a custom 64-bit debug build of Python 2.7.13 (python_d.exe, built with Visual Studio using pcbuild.sln). For the most part, this debug build of Python works with PyDev -- I can configure it as an interpreter and make run/debug sessions. However, the "Attach to Process" feature does not work. If I have a "python_d" process running somewhere on the system and try "Attach to Process" in PyDev, the following happens:
The "Process output" dialog window shows the following:
Connecting to 64 bits target
Injecting dll
Dll injected
Allocating code in target process
Writing code in target process
Allocating return value memory in target process
Injecting code to target process
Waiting for code to complete
Attach finished successfully.
[127156 refs]
Process finished with exitValue: 0
A Windows crash dialog appears saying: "python_d.exe has stopped working"
The "python_d" process to which I was attempting to attach gets this message in its output and then crashes: Fatal Python error: UNREF invalid object
In contrast, the attach mechanism works when I use a regular installed release of Python (which I have configured as a separate interpreter in PyDev).
Are debug builds of Python supposed to work with the PyDev debugger attach mechanism? Is this a bug in PyDev? Could PyDev be improperly using a DLL that is only supposed to be used with Release builds of Python? Does PyDev need to be built from source in a different way in order to support debug builds of Python for this purpose?
Debug builds aren't really supported (the Python ABI is different on debug from release and the code which does the attach is shipped as a dll made to expect the Python release version).
As a note, its code lives on https://github.com/fabioz/PyDev.Debugger/tree/master/pydevd_attach_to_process/dll -- if you really feel this is a must have for you, you can try to change it to work with the debug build of Python.
Most specifically, https://github.com/fabioz/PyDev.Debugger/blob/master/pydevd_attach_to_process/dll/python.h probably needs to be adapted for the debug version.
Related
I am trying to debug a Fortran Console application from Eclipse under Windows 10.
Building and running work fine, using the compiler from MSYS2.
However, starting the debugger yields:
Error in final launch sequence:
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Error creating process /c/Windows/system32/E:/till/uni/wasa/wasa_git/WASA-SED/E:/till/uni/wasa/wasa_git/WASA-SED/wasa_dbg.exe, (error 2).
The gdb.exe is found correctly, but it seems as if the path to the binary is prepended with /c/Windows/system32/ and one time too many the actual path E:/till/uni/wasa/wasa_git/WASA-SED, which obviously causes gdb to fail.
I tried using absolute, relative, and no paths to the binary in the debug configuration settings, all with the same result.
How can I fix this? Thanks in advance.
For me, the problem seems to be related to the version of gdb that I use.
I had used an instance from a recent MSYS2 distribution (i.e. GNU gdb (GDB) 11.1), which produced the error above.
Falling back on an older version (GNU gdb (GDB) 7.9.1) worked as expected.
I solved this by prepending the PATH-variable with the path to the old MSYS2 directory:
SET PATH=c:\mingw4eclipse\bin\;c:\mingw4eclipse\mingw_64\bin\;%PATH%
Putting this into batch file that then calls Eclipse ensures that no other workflows (using the newer MSYS2) are affected.
I am trying to debug tensorflow project, which uses SWIG technique to wrap c++ implementation with python frontend. I want to debug C++ part. Here is what I did:
launch a tensorflow python script in terminal ($pid)
directly using lldb -p $pid works fine, I can set breakpoints, etc.
but I want to use CLion debug GUI, so I click Clion->Run->Attach to Process, find $pid as a native process.
CLion successfully attached to $pid, however, every breakpoint I set in Clion is grey and will not be hit. but if I set breakpoints in embedded lldb console, it works(breakpoint hits and highlight in Clion code file).
the error message on CLion breakpoint is:
Breakpoint will not currently be hit. No executable code is associate
with this line.
P1:
P2:
how to make this right, so that I can set breakpoints in Clion rather lldb command?
Extra information:
tensroflow using bazel to build. I don't use Clion to build. just editing/browsing/debuging. CLion has a bazel plugin, but bind to specific bazel version, not ok for me.
CLion version 2.19.2
I want to create a Go app with a console UI using the termui library (which is built on top of the termbox-go library). I can build the app and run it from the command line, but it will not start inside the GoLand IDE (2018.1.3) on Windows 10.
It fails during the termbox-go init when calling syscall.Syscall with SetConsoleScreenBufferSize parameter. The size for the screen buffer is 80x25. Error message is just "The parameter is incorrect."
How can I debug a termbox-go app in the GoLand or other IDE?
I think the way to solve this is to build your executable with Go 1.10 or newer, compile it with the following flags: -gcflags="all=-N -l" (these are very important and will allow the debugger to work a lot better, and then use the Run | Attach to Local Process... option from GoLand and attach to the local process.
I'll see if I can replicate the bug and update this accordingly.
Before marking this as a duplicate please read the full thread
OS - Windows XP
Primary Language - Java
Scripting Language - Jython
IDE - Intellij Idea
Python Plugin - Pycharm
I am trying to remote debug my application which runs in Java and uses Jython as a scripting language. I followed the steps mentioned in the below link
http://www.jetbrains.com/pycharm/webhelp/run-debug-configuration-python-remote-debug.html#commentsSection
I can start the debugger
When my application starts up, it is able to connect to the debugger
However I am getting below critical WARNING -
pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute)
pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints
pydev debugger: Related bug: http://bugs.python.org/issue1666807
The problem
Debugger doesn't stop at the break points.
I have searched lot of forums for the possible solutions -
delete all *.pyc files
reinstall python version
extract python lib folder to local file and add to sys.path
None of these work for me.
I have a XCode which builds and runs under XCode.
I would like to know if it is possible to debug it using a gdb I build under Mac OSX (gdb 7 to be specified). If yes, can you please tell me how can I do that?
Thank you.
gdb-7.0 reverse debugging currently can only work with two classes of targets:
1) a remote simulator/emulator/virtual-machine that supports going backwards, or
2) the built in "process record" target, which at present has only been ported to x86-linux, x86-64 linux, and moxie linux.
Well, now -- I take that back. I recently discovered that process record can work with any remote x86 target, so if you're connecting with your macintosh target via "target remote", you might just be able to do it!
There is an online tutorial for process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
More info about process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord
And about gdb reverse debugging here:
http://www.sourceware.org/gdb/wiki/ReverseDebug
So you want to use your own version of gdb to debug your executable? Easy!
Open Terminal, and do something like this:
$ cd <directory where Xcode project lives>
$ cd build/Debug (for example - depends on project configuration)
$ /usr/local/bin/my-gdb ./MyExecutable
Of course, specifying the actual path to your custom gdb version.
XCode's debugger is gdb (likely with Apple-specific modifications.) When you debug an application you can get to the gdb command line by opening the Console from the Run menu.
What requirements are imposed on your application that would require you to debug with your own version of gdb?