pyjnius
pyjnius copied to clipboard
CI windows build pass but with errors in log.
As remarked by cmakdonald, the windows builds seem to raise a memory access violation:
all:
BUILD SUCCESSFUL
Total time: 5 seconds
============================= test session starts =============================
platform win32 -- Python 3.6.8, pytest-6.1.1, py-1.9.0, pluggy-0.13.1 -- c:\hostedtoolcache\windows\python\3.6.8\x64\python.exe
cachedir: .pytest_cache
rootdir: D:\a\pyjnius\pyjnius
plugins: cov-2.10.1, rerunfailures-9.1.1
Windows fatal exception: access violation
Current thread 0x00000474 (most recent call first):
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\six.py", line 856 in __new__
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\jnius\reflect.py", line 20 in <module>
File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
File "<frozen importlib._bootstrap_external>", line 678 in exec_module
File "<frozen importlib._bootstrap>", line 665 in _load_unlocked
File "<frozen importlib._bootstrap>", line 955 in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 971 in _find_and_load
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\jnius\__init__.py", line 42 in <module>
File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
File "<frozen importlib._bootstrap_external>", line 678 in exec_module
File "<frozen importlib._bootstrap>", line 665 in _load_unlocked
File "<frozen importlib._bootstrap>", line 955 in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 971 in _find_and_load
File "D:\a\pyjnius\pyjnius\tests\test_arraylist.py", line 3 in <module>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\assertion\rewrite.py", line 171 in exec_module
File "<frozen importlib._bootstrap>", line 665 in _load_unlocked
File "<frozen importlib._bootstrap>", line 955 in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 971 in _find_and_load
File "<frozen importlib._bootstrap>", line 994 in _gcd_import
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\importlib\__init__.py", line 126 in import_module
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\pathlib.py", line 517 in import_path
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\python.py", line 571 in _importtestmodule
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\python.py", line 503 in _getobj
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\python.py", line 294 in obj
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\python.py", line 519 in _inject_setup_module_fixture
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\python.py", line 506 in collect
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\runner.py", line 340 in <lambda>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\runner.py", line 310 in from_call
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\runner.py", line 340 in pytest_make_collect_report
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\callers.py", line 187 in _multicall
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 87 in <lambda>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 93 in _hookexec
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\hooks.py", line 286 in __call__
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\runner.py", line 457 in collect_one_node
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 800 in genitems
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 626 in perform_collect
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 323 in pytest_collection
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\callers.py", line 187 in _multicall
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 87 in <lambda>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 93 in _hookexec
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\hooks.py", line 286 in __call__
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 312 in _main
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 257 in wrap_session
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\main.py", line 306 in pytest_cmdline_main
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\callers.py", line 187 in _multicall
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 87 in <lambda>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\manager.py", line 93 in _hookexec
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\pluggy\hooks.py", line 286 in __call__
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\config\__init__.py", line 165 in main
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\site-packages\_pytest\config\__init__.py", line 187 in console_main
File "C:\hostedtoolcache\windows\Python\3.6.8\x64\Scripts\pytest.exe\__main__.py", line 7 in <module>
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\runpy.py", line 85 in _run_code
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\runpy.py", line 193 in _run_module_as_main
collecting ... collected 161 items
But then go on to mark all tests as successful, which is quite peculiar.
anyone ever figure this out?
Adding the below code to tests/__init__.py suppressed the messages. Courtesy of jpype-project/jpype#561.
try:
import faulthandler
faulthandler.enable()
faulthandler.disable()
except:
pass
Adding the below code to
tests/__init__.pysuppressed the messages. Courtesy of jpype-project/jpype#561.except: pass
Avoid catch-all exception handlers.
At the least change it to except Exception so it stop trapping CTRL-C and similar, but far better to enumerate the exceptions you are concerned about so that real problems are not ignored.
kivy/kivy is suffering the same issue, and we risked to fail to find a bug before having a release: https://github.com/kivy/kivy/issues/8484
On PyTerrier, we used pytest -p no:faulthandler in the GHA and the problem went away.
All the test cases worked fine when run without faulthandler, so I think its just an interplay between pytest doing something with the faulthandler and Java needing it not to be touched.
I tried pytest -p no:faulthandler yesterday on kivy/kivy.
The stacktrace disappeared, but the CI did not failed (as it should).
Did the CI failed (if it was expected to) on your use-case?
If you remove the faulthandler by adding -p no:faulthandler, then the actual problem is gone. There is no need for the process to have a non-zero exit code.
There maybe a bug in Pytest in the process exit code for when the faulthandler does kick in BUT the interplay with Java's signal handler is clearly part of problem here.
To report an issue for PyTest, a minimum reproducible case would need to show that python code raising an SIGTERM is incorrectly handled in PyTest.
If you remove the faulthandler by adding -p no:faulthandler, then the actual problem is gone. There is no need for the process to have a non-zero exit code.
FYI, I've just added -p no:faulthandler to our kivy-sdk-packager job (which differently from kivy/kivy is failing), and now we have a failure, in the middle of the tests, but without the stacktrace.
See: https://github.com/kivy/kivy-sdk-packager/actions/runs/7037739831/job/19153199996?pr=95
So, at least in this case, the problem does not disappear, but instead will just be hidden (if applied on kivy/kivy)
Do you instead get an hserr pid log file, ie the Java signal handler does its thing instead?