I’m currently in the process of porting software from Python 2.7 to Python 3.7, and I’m seeing something that I have no idea how to address. When I type “python –m project.main” to run the software, about 50% of the time nothing happens and a fresh command prompt line prints after a few seconds with no error message or traceback whatsoever. The other half of the time, the program runs perfectly. There doesn’t appear to be any discernable pattern of success vs failure
To try and gather further information, I tried out Python 3’s “faulthandler” package, but most of the time I still see no error message. Once in a while, it does print a cryptic “Windows fatal exception: access violation” with accompanying traceback (but no further details), but again there seems to be no pattern as to when the message prints among the failed runs.
As background, the software builds a QApplication (PyQt5), and we’re running on Windows 10 with Anacdona 3.7. As I mentioned, we recently upgraded from Python 2.7, and never saw anything like this. Most of the migration has gone relatively smoothly – like I said, when the program does run, it works fine.
Has anyone else encountered anything like this? The apparent randomness of the failures is driving me crazy.
Related
I am trying to run a GUI test using pytest and pywinauto. When I run the code normally, it does not complain.
However, when I am doing it via pytest, it throws a bunch of errors:
Windows fatal exception: code 0x8001010d
Note that the code still executes without problems and the cases are marked as passed. It is just that the output is polluted with these weird Windows exceptions.
What is the reason for this. Should I be concerned?
def test_01():
app = Application(backend='uia')
app.start(PATH_TO_MY_APP)
main = app.window(title_re="MY_APP")
main.wait('visible', timeout=8) # error occurs here
time.sleep(0.5)
win_title = f"MY_APP - New Project"
assert win_title.upper() == main.texts()[0].upper() # error occurs here
This is an effect of a change introduced with pytest 5.0.0. From the release notes:
#5440: The faulthandler standard library module is now enabled by default to help users diagnose crashes in C modules.
This functionality was provided by integrating the external pytest-faulthandler plugin into the core, so users should remove that plugin from their requirements if used.
For more information see the docs: https://docs.pytest.org/en/stable/usage.html#fault-handler
You can mute these errors as follows:
pytest -p no:faulthandler
I had the same problem with Python 3.7.7 32-bit and pytest 5.x.x. It was solved by downgrading pytest to v.4.0.0:
python -m pip install pytest==4.0
Perhaps all Python versions are not compatible with the newest pytest version(s).
My workaround for now is to install pytest==4.6.11
With 5.0.0 the problem occurs the first time.
W10 box.
Have this problem using pytest 6.2.5 and pytest-qt 4.0.2.
I tried np8's idea: still got a horrible crash (without message).
I tried Felix Zumstein's idea: still got a horrible crash (without message).
Per this thread it appears the issue (in 'Doze) is a crap DLL.
What's strange is that pytest-qt and the qtbot fixture seem to work very well... until I get to this one test. So I have concluded that I have done something too complicated in terms of mocking and patching for this crap 'Doze DLL to cope with.
For example, I mocked out two methods on a QMainWindow subclass which is created at the start of the test. But removing these mocks did not solve the problem.
I have so far spent about 2 hours trying to understand what specific feature of this test is so problematic. I am in fact trying to verify the functioning of a method on my main window class which "manufactures" menu items (QWidgets.QAction) based on about 4 parameters.
At this stage I basically have no idea what this "problem feature" is, but it might be the business of inspecting and examining the returned QAction object.
After messing around with Python this evening I've managed to get the error message in the title.
I'm new to Python so I wasn't expecting to master it overnight but somehow I've managed to break the most rudimentary feature.
The last thing that happened before it broke was installing Lapack.
Running Windows 10, Python 2.7
Any advice? Hoping not to have to uninstall and start again.
Thanks.
I'm working on a variscite board with a yocto distribution and python 2.7.3.
I get sometimes a Bus error message from the python interpreter.
My program runs normally at least some hours or days before the error ocours.
But when I get it once, I get it directly when I try to restart my program.
I have to reboot before the system works again.
My program uses only a serial port, a bit usb communication and some tcp sockets.
I can switch to another hardware and get the same problems.
I also used the python selftest with
python -c "from test import testall"
And I get errors for these two tests
test_getattr (test.test_builtin.BuiltinTest) ... ERROR test_nameprep
(test.test_codecs.NameprepTest) ... ERROR
And the selftest stops always at
test_callback_register_double (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... Segmentation
fault
But when the systems runs some hours the selftests stops earlier at
ctypes.macholib.dyld
Bus error
I checked the RAM with memtester, it seems to be okay.
How I can find the cause for the problems?
Bus errors are generally caused by applications trying to access memory that hardware cannot physically address. In your case there is a segmentation fault which may cause dereferencing a bad pointer or something similar which leads to accessing a memory address which physically is not addressable. I'd start by root causing the segmentation fault first as the bus error is the secondary symptom.
A year later I found the indirect cause for the problems.
I wrote a crc16 module which used:
from ctypes import c_ushort
...
value = c_ushort(crcValue >>8 ) ...
In case of a BUS-Error this was the problematic part.
I don't assume that the c_ushort() function itself causes the problem, it's only the function which shows that there is something broken.
The problem gone after upgrading the system to Linux version 3.14.38-6QP+g8740b9f (test#Yocto) (gcc version 4.9.2 (GCC) )
I've been using deluged on my Linux PC (Debian) without any problems. Lately I've started to run it on my Mac mini (OSX Lion 10.7.4) and there are several issues:
1- After I start it up using
/Applications/Deluge.app/Contents/MacOS/deluged
it starts with several warning and/or error messages such as:
/Applications/Deluge.app/Contents/Resources/lib/python/twisted
/internet/_sslverify.py:184: UserWarning: You do not have the
service_identity module installed. Please install it from
<https://pypi.python.org/pypi/service_identity>...
I've installed service_identity. On the installed modules script it appears as:
'service-identity==14.0.0'
But still, the same warning message appears on startup.
2- More importantly, after several days sometimes after several hours of operation deluged seems to do excessive read/writes on the harddisk. To stop it from overworking the harddisk, I try to stop the deluged process using kntrl-C on the command line but most of the time it doesn't stop, particularly if it's been working for more than several hours. I have to stop it from GUI activity monitor of OSX using the 'force quit'; it can't be stopped using the plain 'quit'. Here's a screenshot where I try to stop it
Is there anything I can do to solve these problems? Thanks.
I'm getting a Tkinter error even though it was imported and used yesterday. I have a Windows 7 OS and am running Python 2, so I'm not sure what I'm supposed to do at this point. My google-fu is weak today, I can't seem to bring up anything relevant. Any input would be greatly appreciated.
You may want to check if the version of the Python interpreter used to run the script got changed somehow.
import tkinter works in python 3 (instead of Tkinter).
This happens when you most likely have more than one Python installed on your system and you're running the program from a version different from the one you programmed it in.
By default, a Python program on your PC will usually be opened in the latest edition of Python.