You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think what's happening is that when pytest is processing the exception, the traceback holds references to local objects (including the robot) and so the robot and related objects (in some cases) are never fully freed, so when the hal handles and other things are cleared at the end of the test those objects are all orphaned. Several solutions come to mind:
find a pytest hook that runs when we need it to happen and use that instead of at the end of the robot fixture
Run the resets at the beginning of the next function instead
We can technically run each tests in a new process now since the CLI doesn't have to import the robot code.. that would not be ideal, but many of these sorts of issues might disappear.
I think what's happening is that when pytest is processing the exception, the traceback holds references to local objects (including the robot) and so the robot and related objects (in some cases) are never fully freed, so when the hal handles and other things are cleared at the end of the test those objects are all orphaned.
I concur here.
We can technically run each tests in a new process now since the CLI doesn't have to import the robot code.
I've used pytest-forked previously, but that doesn't work on Windows.
Maybe it's time to solve #212 and use pytest-xdist?
I think what's happening is that when pytest is processing the exception, the traceback holds references to local objects (including the robot) and so the robot and related objects (in some cases) are never fully freed, so when the hal handles and other things are cleared at the end of the test those objects are all orphaned. Several solutions come to mind:
I believe this is causing robotpy/robotpy-navx#30, but I don't have conclusive proof.
The text was updated successfully, but these errors were encountered: