Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Random assertions failing in test.py #31

Closed
satta opened this issue Jan 22, 2018 · 3 comments · May be fixed by #408
Closed

Random assertions failing in test.py #31

satta opened this issue Jan 22, 2018 · 3 comments · May be fixed by #408

Comments

@satta
Copy link

satta commented Jan 22, 2018

I'm maintaining py-filelock for Debian (https://packages.qa.debian.org/p/python-filelock.html). We are runningtest.py in a clean chroot during the package build to verify that all tests pass in the version to be packaged. However, we recently noticed that current versions of the library fail their test.py runs with random assertions being hit:

PYTHONPATH=. python2 /build/python-filelock-3.0.0/debian/test.py
.........FF..F........
======================================================================
FAIL: test_threaded1 (__main__.FileLockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python-filelock-3.0.0/debian/test.py", line 233, in test_threaded1
    threads1[i].join()
  File "/build/python-filelock-3.0.0/debian/test.py", line 66, in join
    raise (wrapper_ex.__class__, wrapper_ex, self.ex[2])
AssertionError

======================================================================
FAIL: test_timeout (__main__.FileLockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python-filelock-3.0.0/debian/test.py", line 253, in test_timeout
    self.assertRaises(filelock.Timeout, lock2.acquire, timeout=1)
AssertionError: Timeout not raised

======================================================================
FAIL: test_default_timeout (__main__.SoftFileLockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/python-filelock-3.0.0/debian/test.py", line 278, in test_default_timeout
    self.assertRaises(filelock.Timeout, lock2.acquire)
AssertionError: Timeout not raised

----------------------------------------------------------------------
Ran 22 tests in 6.045s

Patching the source to revert cb1d83d seems to reliably fix the issue but I'm not sure stray lock files are left lying around. Any comments?
@AdorablePotato
Copy link
Contributor

The test for the SoftFileLock fails only because of the FileLockTest. This is a bug in the test.py module. So the SoftFileLock is fine.

The bug in the FileLock is probably caused by the race conditions described in this stackoverflow question. Because the lock file is meant as a simple synchronization mechanism, I think the best solution would be to revert cb1d83d, although not very satisfying.

Side note: Do you know if this bug exists under windows too?

AdorablePotato pushed a commit that referenced this issue Jan 22, 2018
*undo* cb1d83d (clean up the lockfile under unix) (issue #31)
a41e686
@satta
Copy link
Author

satta commented Jan 23, 2018

The bug in the FileLock is probably caused by the race conditions described in this stackoverflow question. Because the lock file is meant as a simple synchronization mechanism, I think the best solution would be to revert cb1d83d, although not very satisfying.

OK. I've added this patch to the package for now.

Side note: Do you know if this bug exists under windows too?

No idea, unfortunately I don't have a Windows system around at the moment to test.

@AdorablePotato
Copy link
Contributor

I think I can close this issue. If the bug still occurs, feel free to reopen it.

@nijel nijel mentioned this issue Feb 22, 2018
Closed
nijel added a commit to WeblateOrg/weblate that referenced this issue Feb 22, 2018
@nijel
Replace own lock implementation by py-lockfile
48b0da7 
We used to have own code to handle this as other lock implementations
either were not reentrant or did not support Windows, but py-lockfile
now supports both of that.

This way also we get tested locking implementation and we can avoid
problems somebody else has already discovered, see
tox-dev/filelock#31

Fixes #1787

Signed-off-by: Michal Čihař <[email protected]>
@taers232c taers232c mentioned this issue Nov 4, 2019
Merged
jay0lee referenced this issue in GAM-team/GAM Nov 5, 2019
@taers232c @jay0lee
Fix race condition/fix rename labels (#1043)
6e9068c 
* Fix race condition

From filelock.py in UnixFileLock
        # Do not remove the lockfile:^M
        #^M
        #   https://github.com/benediktschmitt/py-filelock/issues/31^M
        #   https://stackoverflow.com/questions/17708885/flock-removing-locked-file-without-race-condition^M

* Encode (){} in label: query
@xkortex xkortex mentioned this issue Sep 21, 2020
Closed
@TheMatt2 TheMatt2 mentioned this issue Mar 24, 2023
Closed
This was referenced Apr 5, 2023
Closed
Merged
NMAC427 added a commit to pydiverse/pydiverse.pipedag that referenced this issue Jun 13, 2023
@NMAC427
fix: don't delete file after filelock release to prevent race condition
38e2f83 
tox-dev/filelock#31
@Wauplin Wauplin mentioned this issue Sep 19, 2023
Merged
@dallmann-uniwue dallmann-uniwue mentioned this issue Sep 3, 2024
Merged
4 tasks
sbc100 added a commit to sbc100/emscripten that referenced this issue Apr 2, 2025
@sbc100
Cleanup lock files in UNIX
8349598 
See tox-dev/filelock#31
And https://stackoverflow.com/a/51070775

Without this change the `cache/symbol_lists` directory ends up full of
many lock files that might never get cleaned up.
sbc100 added a commit to sbc100/emscripten that referenced this issue Apr 2, 2025
@sbc100
Cleanup lock files in UNIX
89502dc 
See tox-dev/filelock#31
And https://stackoverflow.com/a/51070775

Without this change the `cache/symbol_lists` directory ends up full of
many lock files that might never get cleaned up (At least since emscripten-core#24029
landed).
@sbc100 sbc100 mentioned this issue Apr 2, 2025
Merged
sbc100 added a commit to sbc100/emscripten that referenced this issue Apr 2, 2025
@sbc100
Cleanup lock files in UNIX
dd68169 
See tox-dev/filelock#31
And https://stackoverflow.com/a/51070775

Without this change the `cache/symbol_lists` directory ends up full of
many lock files that might never get cleaned up (At least since emscripten-core#24029
landed).
sbc100 added a commit to sbc100/filelock that referenced this issue Apr 2, 2025
@sbc100
Enable removal of UNIX lock files
c855e4c 
This avoids leaving orphan locks files around after we are done when
them.

See emscripten-core/emscripten#24035

Fixes: tox-dev#31
@sbc100 sbc100 mentioned this issue Apr 2, 2025
Open
sbc100 added a commit to sbc100/filelock that referenced this issue Apr 2, 2025
@sbc100
Enable removal of UNIX lock files
b350801 
This avoids leaving orphan locks files around after we are done when
them.

See emscripten-core/emscripten#24035

Fixes: tox-dev#31
sbc100 added a commit to emscripten-core/emscripten that referenced this issue Apr 2, 2025
@sbc100
Cleanup lock files in UNIX (#24035)
f51916e 
See tox-dev/filelock#31 and
https://stackoverflow.com/a/51070775.

Without this change the `cache/symbol_lists` directory ends up full of
many lock files that might never get cleaned up (At least since #24029
landed).

I'm also sending this change upstream:
tox-dev/filelock#408
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Enable removal of UNIX lock files sbc100/filelock
2 participants
@satta @AdorablePotato