Bug#990560: Error message "Value too large for defined data type"

2022-12-17 Thread Helge Deller 

On 12/16/22 23:19, James McCoy wrote:

However, I'm not sure changing subversion's build alone will address the
problem.  APR may need a similar change.


I'll look into apr as well.
Note that #1026235 is relevant as well - it changed the behaviour of
some calls, which is why this problem pops up now.
In any way, it would be great (and correct) to build subversion with +lfs.

Thanks!
Helge

Bug#990560: Error message "Value too large for defined data type"

2022-12-16 Thread James McCoy 
On Tue, Dec 13, 2022 at 07:08:29PM +0100, Helge Deller wrote:
> tag: hppa, lfs, patch
> 
> This bug usually indicates that a 32-bit application uses
> functions like readdir() which (by default on a 32bit platform)
> can only handle 32-bit values for inode numbers.
> You can overcome that issue by recompiling the code while providing
> "-D_FILE_OFFSET_BITS=64" on the gcc command line.

Thanks for the investigation.  Subversion is using libapr to perform the
directory listing, which builds with -D_LARGEFILE64_SUPPORT but not
-D_FILE_OFFSET_BITS=64.

Subversion itself also builds with -D_LARGEFILE64_SUPPORT and (for the
Perl bindings) -D_FILE_OFFSET_BITS=64.  It should probably be consistent
about that, which your suggestion would enforce.

> In this specific case I suggest to add the "future=+lfs" option
> to debian/rules  like this (copy/pasted here - may not apply cleanly but you 
> get the idea):

I'll need to double check whether this affects the ABI of subversions
library.  Hopefully not, since it tends to defer to APR for OS-specific
things.

However, I'm not sure changing subversion's build alone will address the
problem.  APR may need a similar change.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#990560: Error message "Value too large for defined data type"

2022-12-13 Thread Helge Deller 

tag: hppa, lfs, patch

This bug usually indicates that a 32-bit application uses
functions like readdir() which (by default on a 32bit platform)
can only handle 32-bit values for inode numbers.
You can overcome that issue by recompiling the code while providing
"-D_FILE_OFFSET_BITS=64" on the gcc command line.

In this specific case I suggest to add the "future=+lfs" option
to debian/rules  like this (copy/pasted here - may not apply cleanly but you 
get the idea):

--- debian/rules   2022-12-13 17:30:09.631676544 +
+++ debian/rules.org   2022-12-13 17:56:43.086922122 +
@@ -14,9 +14,9 @@

 # Workaround an issue with PIC/PIE on certain architectures (c.f., #942798)
 ifneq (,$(filter x32,$(DEB_HOST_ARCH)))
+  DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie future=+lfs
-  DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
 else
+  DEB_BUILD_MAINT_OPTIONS=hardening=+all future=+lfs
-  DEB_BUILD_MAINT_OPTIONS=hardening=+all
 endif

This option enables large file support (LFS) generally. On 64-bit
platforms the aove future-flag is a no-op.

By the way, I think you couldn't reproduce the issue on i386, because
you probably didn't used a huge hard disc there. The issue only arises
sometimes if the searched/read file is above the 32-bit boundary on disc.

Dear subversion maintainers:
Please add the future option.

(I noticed that bug too, because for me "git" package failed to compile,
because it uses subversions in it's tests and subversion there ran into
this "Value too large" problem.)

Helge

Bug#990560: Error message "Value too large for defined data type"

2021-07-15 Thread Bernhard 
Hello James

Attached there is the log.

Best regards
Bernhard


Am Donnerstag, dem 15.07.2021 um 00:17 -0400 schrieb James McCoy:
> On Tue, Jul 13, 2021 at 01:54:20PM +, Bernhard wrote:
> > Hello James
> > 
> > Thanks for working at this topic.
> > Attached, there is the Log file.
> 
> Guess that was too limiting.  Can you run again without "-e trace=file"?
> 
> > Interesting is:
> > At x86 (x86_64 and i386), there are no such problems.
> > This problem is only at armhf architecture.
> 
> Thanks for the clarification on the arch.  That is likely relevant.
> 
> Cheers,

execve("/usr/bin/svnadmin", ["svnadmin", "lstxns", "/storage/subversion/svn"], 0xbed9a780 /* 14 vars */) = 0
brk(NULL)   = 0x218e000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f6c000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17600, ...}) = 0
mmap2(NULL, 17600, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f67000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_repos-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\360\204\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=169416, ...}) = 0
mmap2(NULL, 233500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f0b000
mprotect(0xb6f34000, 61440, PROT_NONE)  = 0
mmap2(0xb6f43000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0xb6f43000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0,6\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=34308, ...}) = 0
mmap2(NULL, 98392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ef2000
mprotect(0xb6efa000, 61440, PROT_NONE)  = 0
mmap2(0xb6f09000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0xb6f09000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_delta-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0hH\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=75268, ...}) = 0
mmap2(NULL, 139340, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ecf000
mprotect(0xb6ee, 65536, PROT_NONE)  = 0
mmap2(0xb6ef, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0xb6ef
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_subr-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200e\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=387152, ...}) = 0
mmap2(NULL, 451284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e6
mprotect(0xb6ebc000, 61440, PROT_NONE)  = 0
mmap2(0xb6ecb000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5b000) = 0xb6ecb000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libapr-1.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320\251\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=142532, ...}) = 0
mmap2(NULL, 206908, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e2d000
mprotect(0xb6e4f000, 61440, PROT_NONE)  = 0
mmap2(0xb6e5e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0xb6e5e000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5[\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=113596, ...}) = 0
mmap2(NULL, 152152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e07000
mprotect(0xb6e1a000, 61440, PROT_NONE)  = 0
mmap2(0xb6e29000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0xb6e29000
mmap2(0xb6e2b000, 4696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e2b000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Y\253\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=973416, ...}) = 0
mmap2(NULL, 1042632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d08000
mprotect(0xb6df2000, 61440, PROT_NONE)  = 0
mmap2(0xb6e01000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe9000) = 0xb6e01000
mmap2(0xb6e05000, 6344, PROT_READ|PROT_WRITE,

Bug#990560: Error message "Value too large for defined data type"

2021-07-14 Thread James McCoy 
On Tue, Jul 13, 2021 at 01:54:20PM +, Bernhard wrote:
> Hello James
> 
> Thanks for working at this topic.
> Attached, there is the Log file.

Guess that was too limiting.  Can you run again without "-e trace=file"?

> Interesting is:
> At x86 (x86_64 and i386), there are no such problems.
> This problem is only at armhf architecture.

Thanks for the clarification on the arch.  That is likely relevant.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#990560: Error message "Value too large for defined data type"

2021-07-13 Thread Bernhard 
Hello James

Thanks for working at this topic.
Attached, there is the Log file.

Interesting is:
At x86 (x86_64 and i386), there are no such problems.
This problem is only at armhf architecture.

Best regards
Bernhard


Am Montag, dem 12.07.2021 um 23:18 -0400 schrieb James McCoy:
> On Fri, Jul 02, 2021 at 06:44:13AM +, Bernhard wrote:
> > At server side, i got the message:
> > 
> > > $ svnadmin lstxns /storage/subversion/svn
> > > svnadmin: E75: Can't read directory 
> > > '/storage/subversion/svn/db/transactions': Value too large for defined 
> > > data type
> > > 
> 
> Looking at APR's source, it looks like this is coming from a call to
> readdir_r but APR should be using readdir.
> 
> Could you run "strace -o lstxns.log -e trace=file svnadmin lstxns
> /storage/subversion/svn" and attach lstxns.log?
> 
> Cheers,

execve("/usr/bin/svnadmin", ["svnadmin", "lstxns", "/storage/subversion/svn"], 0xbe879778 /* 14 vars */) = 0
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_repos-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_delta-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_subr-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libapr-1.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs_fs-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs_x-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs_base-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs_util-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libaprutil-1.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libexpat.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libz.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsqlite3.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/liblz4.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libutf8proc.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libuuid.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libdl.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libdb-5.3.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libcrypt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/gconv/gconv-modules.cache", O_RDONLY) = 3
access("/dev/random", R_OK) = 0
openat(AT_FDCWD, "/storage/subversion/svn/format", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/fs-type", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/fs-type", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/format", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/uuid", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/min-unpacked-rev", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/fsfs.conf", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/storage/subversion/svn/db/transactions", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 3
+++ exited with 1 +++


signature.asc
Description: This is a digitally signed message part

Bug#990560: Error message "Value too large for defined data type"

2021-07-12 Thread James McCoy 
On Fri, Jul 02, 2021 at 06:44:13AM +, Bernhard wrote:
> At server side, i got the message:
> 
> > $ svnadmin lstxns /storage/subversion/svn
> > svnadmin: E75: Can't read directory 
> > '/storage/subversion/svn/db/transactions': Value too large for defined data 
> > type
> > 

Looking at APR's source, it looks like this is coming from a call to
readdir_r but APR should be using readdir.

Could you run "strace -o lstxns.log -e trace=file svnadmin lstxns
/storage/subversion/svn" and attach lstxns.log?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#990560: Error message "Value too large for defined data type"

2021-07-02 Thread Bernhard 
Package: subversion
Version: 1.14.1-3
Severity: important

Hello,

I updated my Server to Debian 11.
Hardware is Banana Pi M3 with Processor Allwinner A83T: 
https://linux-sunxi.org/A83T

The repository was completely new setup with "dump" and "load" with this 
version 1.14.1-3.
Filesystem is XFS.
I run the server using FSFS database and svnserve server.

Now, i got the error message from client after "svn commit":

<-- Snip -->
> Übertrage Daten ...erledigt
> Übertrage Transaktion...
> Revision 2338 übertragen.
> 
> Warnung: post commit FS processing had error:
> Can't read directory '/storage/subversion/svn/db/transactions/2337-1sx.txn': 
> Value too large for defined data type
> 

At server side, i got the message:

> $ svnadmin lstxns /storage/subversion/svn
> svnadmin: E75: Can't read directory 
> '/storage/subversion/svn/db/transactions': Value too large for defined data 
> type
> 

This is the first error message after 4 successfull commits.

Commit was successfully and there is no data loss.
But there was the error message.

Best regards
Bernhard



signature.asc
Description: This is a digitally signed message part