[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
flock test failures on Solaris and MacOS X
From: |
Bruno Haible |
Subject: |
flock test failures on Solaris and MacOS X |
Date: |
Mon, 15 Mar 2010 03:06:33 +0100 |
User-agent: |
KMail/1.9.9 |
Hi,
In <http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00068.html>
and <http://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00273.html>
it was reported that the 'flock' tests fail on MacOS X 10.5. This is
still the case today:
test-flock.c:80: assertion failed
/bin/sh: line 1: 62455 Abort trap
FAIL: test-flock
In <http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00415.html>
it was reported that the 'flock' tests fail on Solaris 10. This is
still the case today:
test-flock.c:62: assertion failed
bash: line 5: 16978 Abort (core dumped) EXEEXT=''
srcdir='.' ${dir}$tst
FAIL: test-flock
There was no reaction to these reports. So the 'flock' module is apparently
unmaintained?
Regarding the MacOS X failure, I think most programs can live without flock()
rejecting invalid arguments. Therefore the best solution is to comment out the
part of the test that is revealed too strict.
Regarding the Solaris failure - an attempt to set a shared lock where an
exclusive lock is already set - it should fail according to the Solaris manual
page. Bug in Solaris. It fails on Linux, but - according to the Linux manual
page - should succeed. Bug in Linux. So this test is best commented out on all
platforms. I'm applying this.
With this, the test succeeds on MacOS X and still fails on Solaris - must be a
bug in gnulib's flock replacement or in Solaris' fcntl implementation; to be
investigated.
2010-03-14 Bruno Haible <address@hidden>
* tests/test-flock.c (test_exclusive): Comment out a test that causes
portability problems. Instead use a simpler test.
(main): Check that invalid arguments are rejected only on Linux.
--- tests/test-flock.c.orig Mon Mar 15 02:54:34 2010
+++ tests/test-flock.c Mon Mar 15 02:54:24 2010
@@ -58,9 +58,31 @@
fd2 = open (file, O_RDWR, 0644);
ASSERT (fd2 >= 0);
- r = flock (fd2, LOCK_SH | LOCK_NB);
+ r = flock (fd2, LOCK_EX | LOCK_NB);
ASSERT (r == -1); /* Was unable to acquire a second exclusive
lock. */
+#if 0
+ /* The Linux manual page of flock(2) says:
+ "A process may only hold one type of lock (shared or exclusive) on a
+ file. Subsequent flock() calls on an already locked file will convert
+ an existing lock to the new lock mode."
+ So, the call below should convert the exclusive lock for fd to a shared
+ and thus succeeds. The fact that it doesn't but instead fails is
+ apparently a bug. */
+ /* The Solaris manual page of flock(2) says:
+ "More than one process may hold a shared lock for a file at any given
+ time, but multiple exclusive, or both shared and exclusive, locks may
+ not exist simultaneously on a file. ...
+ Requesting a lock on an object that is already locked normally causes
+ the caller to block until the lock may be acquired. If LOCK_NB is
+ included in operation, then this will not happen; instead, the call
+ will fail and the error EWOULDBLOCK will be returned."
+ So, the call below should fail and set errno to EWOULDBLOCK. The fact
+ that it succeeds is apparently a bug. */
+ r = flock (fd2, LOCK_SH | LOCK_NB);
+ ASSERT (r == -1);
+#endif
+
ASSERT (flock (fd, LOCK_UN) == 0);
ASSERT (close (fd2) == 0);
}
@@ -76,7 +98,9 @@
ASSERT (fd >= 0);
ASSERT (write (fd, "hello", 5) == 5);
- /* Some impossible operation codes which should never be accepted. */
+#if defined __linux__
+ /* Invalid operation codes are rejected by the Linux implementation and by
+ the gnulib replacement, but not by the MacOS X implementation. */
ASSERT (flock (fd, LOCK_SH | LOCK_EX) == -1);
ASSERT (errno == EINVAL);
ASSERT (flock (fd, LOCK_SH | LOCK_UN) == -1);
@@ -85,6 +109,7 @@
ASSERT (errno == EINVAL);
ASSERT (flock (fd, 0) == -1);
ASSERT (errno == EINVAL);
+#endif
test_shared (file, fd);
test_exclusive (file, fd);
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- flock test failures on Solaris and MacOS X,
Bruno Haible <=