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?
Related
This is my first post on stack overflow so I hope I'm doing it properly.
I am currently working on a Terminal User Interface for python applications. I know that there are many ready-to-use libraries such as npyscreen out there, but I wantend to create one as programming excercice. In particular, I wanted to to play with some architectural patterns to learn them.
All that said, I'm currently facing several problems with python curses library, that I'm using as low level interface to the terminal.
The problems arise when I try to resize my terminal. As you can see from the code (see below), I handle the terminal resizing in the main loop, invoking the getmaxyx()() method of my curses window and redrawing what is on the screen accordingly.
The problem is that the screen seems to flicker when I try to resize the terminal.
Moreover, my "curses application" works fine on MacOS but totally crashes on windows (even after installing windows curses).
To handle that I tried to re-write the low-level interfice by using the blessed library. It solved the windows crashing problem, but the flickering still remains.
I can not figure out what the problem is.
Fore those wishing to help me, here follows the github page of the project: Terminal GUI on GitHub
Thank you in advance.
With curses, there's (at least) 3 things to look for:
ncurses can handle SIGWINCH (PDCurses may not)
some Python configurations interfere with ncurses receiving SIGWINCH. If your program never receives KEY_RESIZE (which it's not checking for...), then it's time to file a bug report for Python to get that fixed.
some programs don't actively read keyboard input (and if KEY_RESIZE isn't read, ncurses won't update the screensize. That would make the program crash.
I am currently facing the issue, that multiprocessing in python with fork as starting method causes a crash on Catalina. The same Code worked perfectly fine on Mojave, even without the classic workaround OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES. This line does not seem to have any effect in Catalina anyway. The crash does not result in any catchable exception or traceback, so i am very sorry but i cannot provide more information. It occurs whenever the forked process uses openMP threading, id est spawns threads itself. Does anyone know how to fix the forking behaviour on Catalina ? Using another starting method is probably not an option since i am dealing with none pickable objects.
its kinda hard to determine your cause without a Crash Report.
Attempt this to find your crash reports:
Open the Console application:
Type “Console” into Spotlight or navigate to “Application -> Utilities -> Console.app.” then Click on Crash Reports.
I had similar issue, where Python kept crashing when i was running Ansible, on Mojave..the classic fix was to add "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES"
However, with Catalina this was not the fix for me any longer. I had to deal with missing links to libcrypto openssl on OSX, The openssl this did the trick for me.
Try this script (or run the commands manually) if you indeed have an OpenSSL issue:
https://gist.github.com/cpavlatos/265d5091a89148eec1cfa2d10e200d32
Note: Prior to running the above script, you might want to cd to /usr/local/Cellar/openssl/ and see what version you have then change the script accordingly.
Also, worth checking is this thread:
https://github.com/Homebrew/homebrew-core/issues/44996#issuecomment-543945199
Summarized better here:
https://gist.github.com/llbbl/c54f44d028d014514d5d837f64e60bac#gistcomment-3115206
So I'm working on a Python 3 package and some functionalities are tested within scripts that can run for several hours/days on a remote machine.
Before I started using multiprocessing (on Windows), there was no problem editing the source files, then starting the script and continue editing, because all the imports are resolved immediately and all the code remains in memory unchanged.
With multiprocessing I'm getting syntax errors etc. when I'm in the middle of editing a file and the running script hits an import statement.
What is a safe way to edit my Python sources that doesn't interrupt my programming workflow too much?
I like the fact that I can try out ideas quickly and I don't want to add too many steps between making changes to the code and running it on the remote machine.
My ideas:
Use version control and work on a local copy on my local machine. Problem here: I have to do some of the debugging on the remote machine so I would have to push even minor changes while looking for small mistakes.
Use version control and work on a copy on the remote machine. Problem here: If I understand this correctly, I would have to switch between a "debug" and "test" conda environment. Seems a bit tedious also.
Find a solution to the multiprocessing issue .....
I'm sure there is a way to do this right, can you help me out?
I seem to be getting a Runtime error whilst running my Python script in Blackmagic Fusion.
# "The application has requested the Runtime to terminate it in an unusual way".
This does not happen every time I run the script. It only seems to pop up when I feed the Python script a heavy workload, or if I run the Python script multiple times inside of the Blackmagic Fusion compositing software, without restarting the package. I thought this might be a memory leak, but when I check the CPU memory usage, it does not seem to flinch at all.
Does anyone have any idea what might be causing this, or at least a solution of how I might start to debug the script?
Many thanks.
if you know how to get runtime error, then run your script using pdb
Perhaps this'll help. It's apparently a common error with microsoft visual c++:
http://support.microsoft.com/kb/884538
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