locks-test fail when building subversion-1.10.0 from sources under Linux (Ubuntu 16)

[Juan Gabriel Covas]

Hello,

First time for me building subversion from sources (Linux). I’ve upgraded a server from 1.9 to 1.10 and things seem ok, but I have just one test from “make check” failing.

I’m just wondering if it’s a problem or it may be ignored.

Followed instructions at http://blog.ashodnakashian.com/2012/11/building-subversion-on-ubuntu-12-10/
First on a test VM installed from scratch, later on production server. Same results.

Please let me know if you need any exact versions / output for anything.

Exact Ubuntu version: 16.04.4 LTS (server, not desktop, so pretty minimalistic).

Extract from tests.log:

START: locks-test
PASS: lt-locks-test 1: test that locks can expire
PASS: lt-locks-test 2: lock only
PASS: lt-locks-test 3: lookup lock by path
PASS: lt-locks-test 4: attach lock
PASS: lt-locks-test 5: get locks
PASS: lt-locks-test 6: basic locking
PASS: lt-locks-test 7: test that locking requires proper credentials
PASS: lt-locks-test 8: test that locking is enforced in final commit step
PASS: lt-locks-test 9: dir propchange can be committed with locked child
PASS: lt-locks-test 10: breaking, stealing, refreshing a lock
PASS: lt-locks-test 11: check out-of-dateness before locking
PASS: lt-locks-test 12: lock multiple paths
PASS: lt-locks-test 13: lock callback error
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: lt-locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
PASS: lt-locks-test 15: lock parent and it's child
END: locks-test
ELAPSED: locks-test 0:00:03.594386

Extract from fails.log:
[[[
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: lt-locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
]]]

Thanks for any insight on this.

Regards,

Juan G. Covas

[Philip Martin]

Post by Juan Gabriel Covas
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: lt-locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
PASS: lt-locks-test 15: lock parent and it's child
END: locks-test
ELAPSED: locks-test 0:00:03.594386
[[[
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: lt-locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
]]]

That's odd. You can run just that one test:

cd subversion/tests/libsvn_fs
./fs-test 14

Does it always fail? What sort of filesystem are you using? Is it a
network filesystem?

If you have strace installed you can run:

libtool --mode=execute strace ./locks-test 14 2>&1 | grep failure/write-lock

For a successful test the output should end:

chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)

When the test is working it makes the "write-lock" file readonly (the
chmod) and then two attempts to open it fail. In your case it appears
that the attempts to open the file do not fail.

[Juan Gabriel Covas]

Thanks for your input.

Post by Philip Martin

Post by Juan Gabriel Covas
[[[
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: lt-locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
]]]

cd subversion/tests/libsvn_fs
./fs-test 14

Result:

# ./fs-test 14
PASS: lt-fs-test 14: set/get txn props, commit, validate new rev props

Post by Philip Martin
Does it always fail?

Always Pass when executed individually.

Post by Philip Martin
What sort of filesystem are you using? Is it a
network filesystem?

No network filesystem:
# mount | grep sda1
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

Post by Philip Martin
libtool --mode=execute strace ./locks-test 14 2>&1 | grep failure/write-lock

This is what I get:


/libsvn_fs# libtool --mode=execute strace ./locks-test 14 2>&1 | grep failure/write-lock

unlink("test-obtain-write-lock-failure/write-lock") = 0
open("test-obtain-write-lock-failure/write-lock", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 3
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3
lstat("test-obtain-write-lock-failure/write-lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3

Post by Philip Martin
chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)

Doesn’t seem to be the same


Juan

[Branko Čibej]

Post by Juan Gabriel Covas
 
Thanks for your input.
 

Post by Juan Gabriel Covas
[[[
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL:  lt-locks-test 14: lock/unlock when 'write-lock' couldn't be

obtained

Post by Juan Gabriel Covas
]]]

 

  cd subversion/tests/libsvn_fs
./fs-test 14

 
# ./fs-test 14
PASS:  lt-fs-test 14: set/get txn props, commit, validate new rev props
 

Does it always fail? 

 
Always Pass when executed individually.
 

What sort of filesystem are you using?  Is it a
network filesystem?

 
# mount | grep sda1
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
 

  libtool --mode=execute strace ./locks-test 14 2>&1 | grep

failure/write-lock
 
 
…/libsvn_fs# libtool --mode=execute strace ./locks-test 14 2>&1 | grep
failure/write-lock
unlink("test-obtain-write-lock-failure/write-lock") = 0
open("test-obtain-write-lock-failure/write-lock",
O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 3
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3
lstat("test-obtain-write-lock-failure/write-lock",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3
 

 
chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC)

= -1 EACCES (Permission denied)

open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC)

= -1 EACCES (Permission denied)
 
Doesn’t seem to be the same…

This is extremely strange. Your filesystem appears to be seriously
broken ... it should be impossible to open a read-only file in write
mode. Are you absolutely sure that you're running the tests on /dev/sda1?

Perhaps the chmod() is failing ... what are the actual permissions on
that file when the test has completed?

-- Brane

[Philip Martin]

Post by Juan Gabriel Covas
Thanks for your input.
# ./fs-test 14
PASS: lt-fs-test 14: set/get txn props, commit, validate new rev props

Post by Philip Martin
Does it always fail?

Always Pass when executed individually.

Oops! I gave the wrong executable name. It should be

./locks-test 14

Post by Juan Gabriel Covas

Post by Philip Martin
What sort of filesystem are you using? Is it a
network filesystem?

# mount | grep sda1
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

Post by Philip Martin
libtool --mode=execute strace ./locks-test 14 2>&1 | grep failure/write-lock

…/libsvn_fs# libtool --mode=execute strace ./locks-test 14 2>&1 | grep
failure/write-lock

I got the right executable name here, so the test does fail.

Post by Juan Gabriel Covas
chmod("test-obtain-write-lock-failure/write-lock", 0444) = 0
open("test-obtain-write-lock-failure/write-lock", O_RDWR|O_CLOEXEC) = 3

That is the failure. The chmod sets the file to be read-only (the chmod
returns 0) but the open still returns a writeable file descriptor. The
open should fail.

If you have gdb installed you can check whether the 0444 permissions
have made it to the filesystem (-r--r--r--). Something like:

$ libtool --mode=execute gdb -arg ./locks-test 14
(gdb) b svn_fs_lock_many
(gdb) r
Breakpoint 1
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock
(gdb) b open
(gdb) c
Breakpoint 2
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock
(gdb) fin
(gdb) fin
Value returned is $1 = 13
(gdb) p fname_apr
$2 = 0x7ffff7eea130 "test-obtain-write-lock-failure/write-lock"
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock

The second breakpoint is the open that should fail. The two "fin"
commands return to the Subversion code and the value 13 is EPERM showing
the open failed (because the file has permissions -r--r--r--).

In your case I assume the return value is 0 rather than 13 and the file
permissions are not -r--r--r--.

[Juan Gabriel Covas]

Ok, my mistake.

Post by Philip Martin

SUMMARY: All tests successful.

I got “success” for all the tests from “make check” command after compiling svn from sources NOT using the root account.

First I tried to ensure the build process was using the “apr” and “apr-util” compiled from the subversion-1.10 sources directory, but the same locks-test #14 failed (even forced a “apt-get remove libapr1 libapr1-dev libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-dev libaprutil1-ldap”).

But that was not the problem. Only when I used a non-root account to compile from sources from scratch, all the tests were successfull.

Regards and sorry for the inconvenience,
--
Juan

Post by Philip Martin
If you have gdb installed you can check whether the 0444 permissions

$ libtool --mode=execute gdb -arg ./locks-test 14
(gdb) b svn_fs_lock_many
(gdb) r
Breakpoint 1
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock
(gdb) b open
(gdb) c
Breakpoint 2
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock
(gdb) fin
(gdb) fin
Value returned is $1 = 13
(gdb) p fname_apr
$2 = 0x7ffff7eea130 "test-obtain-write-lock-failure/write-lock"
(gdb) shell ls -l test-obtain-write-lock-failure/write-lock
-r--r--r-- 1 pm pm 0 May 1 13:17 test-obtain-write-lock-failure/write-lock

Post by Philip Martin
The second breakpoint is the open that should fail. The two "fin"
commands return to the Subversion code and the value 13 is EPERM >showing
the open failed (because the file has permissions -r--r--r--).
In your case I assume the return value is 0 rather than 13 and the file
permissions are not -r--r--r--.

[Branko Čibej]

Post by Juan Gabriel Covas
 
 
Ok, my mistake.
 

Post by Philip Martin

SUMMARY: All tests successful.

 
I got “success” for all the tests from “make check” command after
compiling svn from sources NOT using the root account.
 
First I tried to ensure the build process was using the “apr” and
“apr-util” compiled from the subversion-1.10 sources directory, but
the same locks-test #14 failed (even forced a “apt-get remove libapr1
libapr1-dev libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-dev
libaprutil1-ldap”).
 
But that was not the problem. Only when I used a non-root account to
compile from sources from scratch, all the tests were successfull.
 
Regards and sorry for the inconvenience,

Well, well. This does explain the test failure.

But let me give you a hint: Compiling sources as 'root' is, to put it
mildly, just a "bit" dangerous. What if I added an 'rm -rf /' to our
build scripts? By mistake, of course, obviously I'd never do that on
purpose (even if it /would/ be very educational).

-- Brane

 

Post by Juan Gabriel Covas

Post by Philip Martin
If you have gdb installed you can check whether the 0444 permissions

 
  $ libtool --mode=execute gdb -arg ./locks-test 14
  (gdb) b svn_fs_lock_many
  (gdb) r
  Breakpoint 1
  (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
  -r--r--r-- 1 pm pm 0 May  1 13:17
test-obtain-write-lock-failure/write-lock
  (gdb) b open
  (gdb) c
  Breakpoint 2
  (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
  -r--r--r-- 1 pm pm 0 May  1 13:17
test-obtain-write-lock-failure/write-lock
  (gdb) fin
  (gdb) fin
  Value returned is $1 = 13
  (gdb) p fname_apr
  $2 = 0x7ffff7eea130 "test-obtain-write-lock-failure/write-lock"
  (gdb) shell ls -l test-obtain-write-lock-failure/write-lock
  -r--r--r-- 1 pm pm 0 May  1 13:17
test-obtain-write-lock-failure/write-lock
 

Post by Philip Martin
The second breakpoint is the open that should fail.  The two "fin"
commands return to the Subversion code and the value 13 is EPERM >showing
the open failed (because the file has permissions -r--r--r--).

 

Post by Philip Martin
In your case I assume the return value is 0 rather than 13 and the file
permissions are not -r--r--r--.