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.
Related
I'm trying to do the exact same thing as this question:
How to prevent a block of code from being interrupted by KeyboardInterrupt in Python?
(sorry, not enough rep yet to post this as a comment there)
However both of the top answers posted there aren't working for me. When I hit CTRL+C with either of those solutions in place, the script still closes immediately with:
forrtl: error (200): program aborting due to control-C event
The code I'm working on is fairly long and includes quite a few imported modules. Am I correct to assume one of these modules is interfering with the normal behavior of KeyboardInterrupt? If so, how can I figure out which one?
(I'm running python 2.7.6, 32bit on Windows)
thanks.
Scipy was causing the problem. The link below provides a solution, note that this is not unique to scipy.stats, but also occurs with other scipy functions.
Ctrl-C crashes Python after importing scipy.stats
A part from those specific cases above (question and above answer), for those of you still stuck in this
forrtl: error (200): program aborting due to control-C event
trying to obtain a normal behaviour of CTRL+C KeyboardInterrupt during the execution of a program (in my case it's a training procedure of neural network model with PyTorch executed within PyCharm IDE on Windows 10 and anaconda python3.8).
It turned out to be a problem of corrupted anaconda environment or either some package within. For me, reinstalling the previous version of PyCharm (downgrading from 2022 to 2021) and replacing the old environment with a brand new one, solved the problem. The KeyboardInterrupt turned back to its old useful behaviour, stopping the program but not exiting the python console at CTRL+C event.
Hope it helped someone.
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 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
I wish I could provide a simple sample case that occurs using standard library code, but unfortunately it only happens when using one of our in-house libraries that in turn is built on top of sql alchemy.
Basically, the problem is that this break command:
(Pdb) print sqlalchemy.engine.base.__file__
/prod/eggs/SQLAlchemy-0.5.5-py2.5.egg/sqlalchemy/engine/base.py
(Pdb) break /prod/eggs/SQLAlchemy-0.5.5-py2.5.egg/sqlalchemy/engine/base.py:946
Is just being totally ignored, it seems, by pdb. As in, even though I am positive the code is being hit (both because I can see log messages, and because I've used sys.settrace to check which lines in which files are being hit), pdb is just not breaking there.
I suspect that somehow the use of an egg is confusing pdb as to what files are being used (I can't reproduce the error if I use a non-egg'ed library, like pickle; there everything works fine).
It's a shot in the dark, but has anyone come across this before?
I wonder if somehow there's an old .pyc that can't be deleted because of permissions being messed up. Nuke all of the .pycs in your python-path, and see if that helps.
This blog post might be related to your trouble.
I don't suppose this is yet another problem caused by setuptools? I ask because I notice the ".egg" in that path...
What version of python are running? I observe similar behavior on python 2.7.3. Curiously, I do not see the same behavior on ipython 0.12.1.
In python 2.7.3, the debugger and the stack trace get the point where an exception occurred wrong.
In ipython 0.12.1, the debugger and the stack trace get the point where the exception occurs is correct, but once the exception occurs, then the program exits, which makes post mortem debugging difficult.
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.