search

kivy / pyjnius

Access Java classes from Python
https://pyjnius.readthedocs.org
MIT License
1.4k stars 255 forks source link

CI windows build pass but with errors in log. #561

Open tshirtman opened 4 years ago

tshirtman commented 4 years ago

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.

cmacdonald commented 3 years ago

anyone ever figure this out?

MrFizzyBubbs commented 1 year ago

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
Julian-O commented 1 year ago

Adding the below code to tests/__init__.py suppressed 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.

misl6 commented 11 months ago

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

cmacdonald commented 11 months ago

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.

misl6 commented 11 months ago

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?

cmacdonald commented 11 months ago

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.

misl6 commented 11 months ago

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)

cmacdonald commented 11 months ago

Do you instead get an hserr pid log file, ie the Java signal handler does its thing instead?