How can I ensure a python program can be interrupted via Ctrl-C, or a similar mechanism, when it is deadlocked in code within a DLL?
Not sure if this is exactly what you are asking, but there are issues when trying to interrupt (via Ctrl-C) a multi-threaded python process. Here is a video of a talk about the python Global Interpreter Lock that also discusses that issue:
Mindblowing Python GIL
You might want to take a look at this mailing list for a couple other suggestions, but there aren't any conclusive answers.
I've encountered the issue several times, and I can at least confirm that this happens when using FFI in Haskell. I could have sworn that I once saw something in Haskell's FFI documentation mentioning that DLLs would not return from a ctrl-c signal, but I'm not having any luck finding that document.
You can try using ctrl-break, but that's not working to break out of a DLL in Haskell and I'm doubting it will work in Python either.
Update: ctrl-break does work for me in Python when ctrl-c does not, during a call to a DLL function in an infinite loop.
Related
I have a PyQt application that occasionally will crash due to memory issues with the error shown below
The instruction at 0X00007FFC450FA07 reference memory at 0X0000000000000048. The memory could not be read.
I personally have not been able to reproduce this error in any way. It has happened on the computer's of a few people I work with while running my application. I have looked and see a lot of questions for languages like C# or C++, and it seems to be a pointer issue. Since I am using Python though, these questions and solutions are not very relevant since Python does not use pointers.
Seen here: C# example question the problem here is a long running thread. I do use threading in my application so I have been looking there. I have ran my application many times with the task manager open to monitor threads and have not seen any problems. All threads seem to close. If there is a better way to monitor this please let me know.
I am using PyCharm and my Python version is 3.9. I am also using Pyinstaller to create an executable version of the application. I have ran the program using the command line, launching the executable, and also directly through PyCharm and have not been able to see the error at all or debug it.
Is it possible this is happening due to bit related issues? Meaning that I am compiling my code using a 32-bit version of Python, could some computers have a problem with that? Would compiling with a 64 bit version possibly solve this?
I have tried to find some information on this, but nothing so far. The scenario is a Python program that uses a C based library loaded with ctypes and then encounters an unhandled exception. Will Python unlioad the library? Or will it matter?
The main reason why this is an issue is that the library in question is a device driver, and I want to avoid leaving the hardware in the wrong state should something go wrong.
I'm making a .dll plug-in in c++ and embedding python 2.7 in it.
Everything worked fine with simple .py programs until I imported a large program. The strangest thing is that the program runs with no problem the first time, but the second time an exception is raised:
Unhandled exception at 0x6731ADA1 (multiarray.pyd) in EuroScope.exe: 0xC0000005: Access violation writing location 0x00000001.
(The Lib/Dll folders and modules are all copied to the .exe folder)
I've searched the web and there are a couple of persons with the same error but the solutions that worked for them don't for me. For example here
I know this is a very specific error but I'm hoping that someone out there has already managed to work past it.
I won't post the code here because i think it's irrelevant for this bug and also because it's way too long
Edit: I managed to see the problem is specifically in import numpy
I managed to work past this problem. It seems that some modules have problems when their initialization routines are called more than once, and numpyis one of those. The solution is to call Py_Finalize() only once at the very end of the program. Py_Initialize() can be called as many times as you want, as if Python is already initialized, Py_Initialize() is a non-op ...
And also, discovered that this solution turns the application faster since python doesn't need to restart every time there's a call to some of its function.
More information about it here
Similar problem happens with pyHook and pyxhook library. Spent long time to figure out the reason of crash for those two modules but no clue available online. Now I am finding it is happening with numpy too. Hoping this one time Py_Finalize() will solve both of my problems.
The problem is solved after disabling python thread support in my embedded interpreter code by commenting the followings. By the way I am running the interpreter already in a POSIX thread created by my C code.
//PyEval_InitThreads();
//gstate = PyGILState_Ensure();
//PyGILState_Release(gstate);
Now I can run my py.script with numpy and pyHook many times. However it will cause the following error message at the end of the C code if the module thread is imported in python script directly or by any other imported module.
Exception KeyError: KeyError(14288,) in <module 'threading' from 'C:\python27\Lib\threading.pyc'> ignored
Still I feel It needs a better solution.
I'm trying to create a multi threaded program by launching a boost thread which calls a function which in turn calls some python module but the program hangs there as it acquires some PyGILState_Ensure() lock and waits for it to release indefinitely.Can you please tell me what is wrong here.
Yeah actually a python module calls my c++ code which calls another python module in separate threads , thats why I think its waiting for PyGIL to release which results in deadlock , so , is there any solution to it with using the patch for removing PyGIL?
The Python interpreter isn't re-entrant and needs to lock the interpreter while it's being called (see e.g. http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal-patch-of.html). In your particular situation it seems like there's another Python call on the interpreter already running, and it's holding the GIL.
I am running a stand-alone Python v3.2.2/Tkinter program on Windows, not calling any external libraries. Idle has been very helpful in reporting exceptions, and the program has been debugged to the point where none are reported. However, the python interpreter does occasionally crash at non-deterministic times - operations will run fine for a while and then suddenly hang. The crash triggers the standard Windows non-responding process dialog asking if I want to send a crash dump to Microsoft:
"pythonw.exe has encountered a problem and needs to close.
We are sorry for the inconvenience."
Crash reporting in Python says that the interpreter itself rarely crashes. My question is: no matter how many mistakes there are in a python script, is there any way it should in theory be able to crash the interpreter? Since there are no exceptions being reported and the crashes happen at random times, it's hard to narrow down. But if the interpreter is in theory supposed to be crash-proof, then something I'm doing is triggering a bug.
The code (a scrolling strip-chart demonstration) is posted at What is the best real time plotting widget for wxPython?. It has 3 buttons - Run, Stop, Reset. To cause a crash just press the buttons in random order for a minute or so. With no interaction, the demo will run forever without crashing.
Of course, the goal is for something like Python to never crash. Alas, we live in an imperfect world. A more useful question to ask, I think, is "What should I do if Python crashes?". If you want to help make a more perfect world, first make a quick search at the Python issue tracker to see if a similar problem has already been reported and possibly fixed in a newer or as yet unreleased version of Python. If not, see if you can find a way to reproduce the problem with clear directions about steps involved, what OS platform and version, what versions of Python and 3rd-party libraries, as applicable. Then open a new issue with all the details. Keep in mind that Python, like many open source projects, is an all-volunteer project so there can be no guarantee when or if the problem will be more deeply investigated or solved (most issues are resolved eventually) but you can be happy that you have done your part and likely saved someone (maybe many people) time and trouble. If you want other opinions before opening an issue, you could ask about it on the python-list mailing list/news group.
Python isn't indeed 100% crash proof, especially when you using external libraries, which TkInter is.
There is even page dedicated to it: http://wiki.python.org/moin/CrashingPython