Access violation with pytest >= 5.0.0 and windows 10 #7634
Comments
Zac-HD
added
platform: windows
|
Not much we can do without having a way to reproduce this... However, something that might help to find the issue (whether that's in pytest or in your DLL) is a git bisect. This tells us which commit in pytest exactly introduces the issue, by letting git always test the middle between two commits. To do so, run something like this (untested):
Now for the following commands, use two different terminals, one where you do the bisect in the pytest repository, and one where you run pytest in your project directory:
Then, git will check out the middle between the two. Test it, and do |
|
Hello, and thanks a lot for your help. Git bisect was able to pinpoint the "broken" commit, which in the end was the following: /c/Bailly/github_pytestdev_7634/pytest ((a37b902af...)|BISECTING)
$ git bisect bad
a37b902afea21621639b114f087e84f70fb057ba is the first bad commit
commit a37b902afea21621639b114f087e84f70fb057ba
Author: Bruno Oliveira <nicoddemus@gmail.com>
Date: Wed Jun 12 18:49:51 2019 -0300
Integrate pytest-faulthandler into the core
* Add pytest-faulthandler files unchanged
* Adapt imports and tests
* Add code to skip registration of the external `pytest_faulthandler`
to avoid conflicts
Fix #5440
changelog/5440.feature.rst | 8 ++++
doc/en/usage.rst | 19 +++++++-
src/_pytest/config/__init__.py | 3 +-
src/_pytest/deprecated.py | 8 ++++
src/_pytest/faulthandler.py | 102 +++++++++++++++++++++++++++++++++++++++++
testing/deprecated_test.py | 23 ++++------
testing/test_faulthandler.py | 99 +++++++++++++++++++++++++++++++++++++++
7 files changed, 245 insertions(+), 17 deletions(-)
create mode 100644 changelog/5440.feature.rst
create mode 100644 src/_pytest/faulthandler.py
create mode 100644 testing/test_faulthandler.pywhich makes me think it could be related to the issue #7059 and/or #7022. Thanks in advance for any additional information. |
|
The faulthandler integration is just what's printing the "Windows fatal exception: access violation" output. If I had to guess, I'd say the access violation was already happening earlier (In a thread, hence why it's not aborting pytest itself?), it's just that nothing ever told you about it? What happens if you run with pytest 4.6.11 but run |
|
When running that command, I do not get any unexpected output. |
|
To me this looks like the memory layout may be part of the trigger for the fault I suspect an issue in the c library causes the issue, on Linux one would use a memory debugger now, I'm unfamiliar with the tools to use on Windows for such a issue |
|
Some more things that might be interesting:
What about pytest 5.x and |
|
outputs : pytest 4.6.11 pytest 5.4.3 pytest 5.4.3 So yeah... that seems conclusive, I will happily settle with saying the issue is in the DLL, and that pytest actually suffered no regression (on the contrary). |
|
Yep, definitely looks like this isn't pytest fault, only that the faulthandler introduction made you aware of an issue in your DLL. Closing this then! |
|
As Google sent me here and I think I have a similar issue, my problem was with python.net package and my build system. If I set the PROCESSOR_ARCHITEW6432 environment variable to None, I get this issue. Leave it as is ("AMD64") and the problem goes away. |
|
@W2Q3Q1 it's strongly discouraged to chdir a lot, in particular the way used in your example it's very fragile due to order dependency The recommended mechanism is to determine module paths and/or using importlib.resources |
|
@RonnyPfannschmidt It is a very useful comment. But I still cannot explain why Access Violation happened, and I am not sure about the solution I proposed. It seems like an occasional bug. |
|
@W2Q3Q1 the observed bug/issue seems to be a condition that strongly depends on memory layout and external circumstance that in part is the reason why actions like deferring imports to as late as possible have an effect on it loading modules at vastly different times to ensure memory allocations obscure the memory layout are one technique to deter the issue from being triggered when one has no reliable way to detect and resolve the root cause in particular memory layout related triggers for bugs are at times spooky however your code you had pasted bedore also chdirs to the locations of test/code files at seemingly "random" times during both import and function calls, this type of directory switching can lead to quite some confusion depending on which order the imports/code executions happen for usages in tests i strongly recommend either pytests |
|
In my case, the fault was in and now the pipeline have no error. The error happened every time with Before the cure: The error: The cure: After the cure: |
A detailed description of the bug or suggestion:
So, I used to run tests on windows 10 using pytest 3.x.x and custom plugins but I recently upgraded to pytest 5.x.x.
Since then, each time I run a test featuring a call to a DLL using pythonnet 2.5.1, I get a generic windows access violation error.
Even though I found similar cases online, each time accepted fix seemed to be to downgrade pytest - which I do not want to do, as I rather like the new functionalities.
Issue was reproduced with every pytest version above 5.0.0, including 6.0.0+.
Versions under 4.6.11 did not allow me to reproduce the error.
Output of
pip listfrom the virtual environment you are using:my privatevenv pip list:
Package Version
atomicwrites 1.4.0
attrs 19.3.0
colorama 0.4.3
comtypes 1.1.7
importlib-metadata 1.7.0
iniconfig 1.0.1
more-itertools 8.4.0
packaging 20.4
pip 19.0.3
pluggy 0.13.1
py 1.9.0
pycparser 2.20
pyparsing 2.4.7
pytest 5.4.3
pythonnet 2.5.1
pywin32 228
pywinauto 0.6.8
setuptools 40.8.0
six 1.15.0
toml 0.10.1
wcwidth 0.2.5
zipp 3.1.0
pytest and operating system versions:
platform win10 x64 -- Python 3.7.4 32 bits, pytest-5.3.4, py-1.9.0, pluggy-0.13.1
Minimal example if possible:
here is my code for test.py:
and the output I get when executing "pytest test.py":
As an additional question, is there a better way or methodology to troubleshoot this one ?
Thanks.
The text was updated successfully, but these errors were encountered: