I'm trying to debug a c-code dynamic library written via Xcode (7-beta), and the library is wrapped as a Python (2.7.3) module. Swig (v3.0.5 --> http://www.swig.org/) is being used to do the bindings and Xcode to compile and generate the library. It's all running fine. Python is running via PyCharm (CE 4.5.3).
In order to debug the library, I do a debug build, start the module from PyCharm, go to Xcode, menu "debug->attach to process->Python" attach to the process and it works like a charm, programmer's dream (almost). The breakpoints are reached, variables read, etc.
So here's the problem:
While the C code is correcly halted on a breakpoint, the running script in PyCharm is finished (with exit code 0), as if it had naturally reached it's endpoint. Here's a simple situation where the problem is reproduced:
C-code (the dynamic library):
int TestIt(){
return 42;
}
While the Python code is basically:
import time
import my_c_dinamiclib
for i in range(60):
print i, my_c_dynamiclib.TestIt()
time.sleep(1)
So there are 60 seconds to attach to the process.
Does anyone know how to deal with this? I've tried running Python in debug mode, with no success.
Related
I'm trying to run a program that was originally compiled for x86 processors on my raspberry pi, I tried to use the box86 emulator which I installed to launch it but it is returning a long list of errors of the following type.
"Error: Global Symbol XML_SetEncoding not found, cannot apply R_386_BLOB_DAT #0xba19f98 ((nil)) in ~/program/libpython3.9.so.1.0"
and ending with
"Error loading Python lib '/program/libpython3.9.so.1.0': dlopen Cannot dlopen("/program/libpython3.9.so.1.0"/0xb6380560, 102)
I can't find any reference to these type of errors and am unsure if it is something in the setup or due to the box86 emulator? The program I am running is initialised from a .sh and runs a python script, and the libpython3.9.so.1.0 file is located in the directory it is looking in.
I know this is not the best way to go about this but I have been tasked with getting the program running on a pi and if it proves impossible I can try to purchase an industrial pc for the task but I would like to try with this first, My next step will be attempting to see if using exagear may help but assistance with these errors would be useful first.
Edit: I have not done any configuration of python or the path since setting up the Pi, however the file i am running starts with #!/usr/bin/env/ bash
I want to be able to step through C++ code that is part of a dll used by a Python script.
I have looked at https://learn.microsoft.com/en-us/visualstudio/python/debugging-mixed-mode-c-cpp-python-in-visual-studio?view=vs-2019 and I think I've implemented this correctly. However when ever I enable Enable Native code debugging the breakpoints in Python are no longer functioning and it states that no symbols are found in code.
I went to the Visual Studio Python installation and have selected Python native development tools
And the Python symbols have been installed and are present in the active environment:
On the debug tab I have tried setting the interpreter path to python_d.exe and in Debug>Options on the Symbols tab I've selected the associated symbols:
I have tried selecting multiple options in the image above with no success.
I suspect it is something simple that I'm doing wrong, any ideas? Thanks!
I faced the same problem and didn't find a solution.
If you want a workaround, try to attach your native code to the python.exe process:
Start the debugging of your python script (without native support) and wait on some breakpoint
Launch your native project in another VisualStudio instance, set needed breakpoint and then go to Debug -> Attach to process, select started python.exe process (you can find it by PID)
Continue python execution.
It worked for me. Note that you need your native code to be compiled with debug symbols as well.
Happy bug-hunting! =)
I'm currently trying to debug issues in Caffe for Windows PyCaffe.
Because of a bug in Python Tools for Visual Studio, PTVS doesn't work so I'm using PyCharm and trying to attach to PyCaffe's process through Visual Studio 2013. That is, I'm running PyCharm debugger on a Python script with a breakpoint set at the point where I call the Python entry point into PyCaffe.
I debug the Python script in PyCharm which calls modules written in C++ in VS. I want to debug those modules in C++. So I'm trying to attach to the PyCharm or Python processes with breakpoints set in VS.
The problem is that the breakpoint isn't firing at the entry point in PyCaffe in the Visual Studio C++ code.
Has anyone successfully gotten this kind of thing to work or is there an alternative way of doing this?
I faced a similar problem a few years ago, trying to
debug a user-mode driver wish was loading automatically from a RPC, the solution I found was:
Download Debugging Tool for Windows (depending on your system x86 or x64), wish is free,from the Microsoft Download.
Add "__asm int 3"(this is asm instruction for a hardware breakpoint) in the place on the C code where you whant to the break point to take effect.
Compile the C program, nomally with debug info (this part is important,because help the Debugger to find the source file), this should not make any problems.
Attach the Debugger to the running process (in my case was the explorer process), in your case should be the process that make first call to the library, for example if PyCharm create a process for the new python code, the debugger need to be attached to that process(you can manage this by setting a breakpoint in python, wish will give you time for doing the attach process), the easy way for me to figure this out was to let the process crash, because "__asm int 3" cause a process crash if a debugger is not attach, you can take advantage of this waiting for the crash and when windows shows you the screen "Process ... has detected a problem an need to be closed", you know who is the process that you are looking for.
This could be painful the first time but for me quite effective, because you
can see the data flow from one program to another,
We attach to one process and allow to set breakpoints within code that has not started from the VS debugger. But one important issue is that we often debug/run the app in the VS, for example, we debug the Web code that runs under IIS, we will attach to the IIS process or others.
Your project is different from the above sample, you run/debug your app in Pycharm (not the VS), but you want use the VS Attach to process function, so it would have a limitation. As you said that you debug script in PyCharm, and want to call C++, so you would check that whether the PyCharm supports a similar feature like the attach tool in VS.
On Windows7 I have a python script that uses Windows DLLs, using the .NET Common Language Runtime (CLR). An error occurs inside one of the used DLL, but the standard Python debugger only debugs on the Python code level (and not the DLL).
How can I debug what is going on inside the DLL(s)?
If you have Microsoft Visual Studio available,
1) open the Visual Studio project that your DLL is part of (or create a new project).
2) If you have set up your DLL for debugging (you've built it with debugging info, and it will be the one that your python program will use), you can set breakpoints in the DLL code.
3) Start the program you want to debug as you would do normally.
4) Go back to the Visual Studio IDE and go to the Debug menu. Choose the Attach to Process option. You will then get a list of all the running processes.
5) Choose the process you want to debug, which will be your python program, or runtime that is running your program.
6) Sit back and wait for one of your breakpoints to be hit, or you can try a Break All from the Debug menu to temporarily halt the program.
This is a general way of starting out debugging not only python programs, but any program where you need to debug a DLL that is being used by the program.
Note that the above advice works best if you have built the DLL yourself with debugging information and is being utilized by your python application. If it is a third-party DLL where you have no source code, you can still debug from Visual Studio, but will need to know assembly language (since the source code is usually not available).
These 3 debugging scenarios with pythonnet are based on PTVS docs:
https://github.com/pythonnet/pythonnet/wiki/Various-debugging-scenarios-of-embedded-CPython
I've noticed how easy it is to debug a Python script from Eclipse. Simply set breakpoints and run a Python script from the debug menu. But is it possible to start a Python Interactive Interpreter instead of running a particular Python script, whilst still having Eclipse breaking on breakpoints? This would make it so much easier to test functions.
Thanks for any help
Still looking for a simple/ish way to start the debugger in Eclipse->PyDev that lets me use the interactive debugger. None of the answers as of yet is acceptable
You can explicitly write code to setup a breakpoint in your script, and then "remote debug". That means having pydevd in the pythonpath of your script wherever it is running, and running the eclipse pydev remote debugger on your devbox. If it's all happening on the same machine, this is fairly straightforward.
If not, you'll need to specify the hostname of the dev machine running the python remote debugger in the call to settrace(). You'll also need pydevd available on the machine running the script.
I have got this working in the past without having to install eclipse+pydevd on the machine running the script. It's not totally straightforward, and if you go that route I'd recommend checking that the pydevd versions match or at least you know they're compatible. Otherwise you end up wasting time debugging the debugger.
For details see: Pydev Remote Debugger
what about this, in the script, you can write a function, say onlyForTest, then each time you write a new function and want to test it, you can just put it in the onlyForTest function, then specify some arguments required by the new function you just write, then open the interactive python shell, import the script, call the onlyForTest function, check out the result.