SeattleTestbed / repy_v2

Seattle Testbed's Repy ("Restricted Python") sandbox, version 2
MIT License
12 stars 50 forks source link

Lots of CleanupInProgressErrors when running Repy V2 unit tests on a Mac #26

Closed choksi81 closed 6 years ago

choksi81 commented 10 years ago

It is typical for most of the networking unit tests to fail when run on a Mac. (Example failure output below.) This is due to !CleanupInProgressErrors. We should handle this in an intelligent way. I'm going to investigate adding a short sleep / retry to appropriate tests and if this does not work then maybe the tests should choose unique ports in some range.

    Running: ut_repyv2api_connectionserversendblocks.py         [ FAIL ]
--------------------------------------------------------------------------------
Standard error :
..............................Produced..............................

---
Uncaught exception!

---
Following is a full traceback, and a user traceback.
The user traceback excludes non-user modules. The most recent call is displayed last.

Full debugging traceback:
  "repy.py", line 190, in main
  "/Users/justincappos/test2/virtual_namespace.py", line 113, in evaluate
  "/Users/justincappos/test2/safe.py", line 508, in safe_run
  "ut_repyv2api_connectionserversendblocks.py", line 15, in <module>
  "/Users/justincappos/test2/namespace.py", line 1206, in wrapped_function
  "/Users/justincappos/test2/emulcomm.py", line 1316, in openconnection
  "/Users/justincappos/test2/emulcomm.py", line 1104, in _conn_cleanup_check

User traceback:
  "ut_repyv2api_connectionserversendblocks.py", line 15, in <module>

Exception (with class 'exception_hierarchy.CleanupInProgressError'): The socket is being cleaned up by the operating system!

---

..............................Expected..............................
None
-------------------------------------------------------------------------------
choksi81 commented 10 years ago

Author: justinc For my Mac, I need to set the timeout to be > 30 seconds for this to work. It fixes the issue, but I really think we need a better solution.

I looked and it seems that calling shutdown may be able to prevent this. Is the answer as easy as calling this before close / garbage collection? http://docs.python.org/library/socket.html#socket.socket.close

Unfortunately, I'm starting to get off in the weeds with this and need to fix the problem I was originally working on. Someone else should feel free to take this ticket.

choksi81 commented 10 years ago

Author: vijay For my Mac , I modified the test case by making it to sleep for 6 seconds before performing receive operation on a closed socket and it fixed the issue.

We are already shutting down the socket prior to closing it.

I need to dig deep into this issue and this is only on Mac OS X .