Your message dated Mon, 7 Dec 2009 01:28:46 +0100
with message-id <[email protected]>
and subject line Re: Bug#559376: Acknowledgement (pwrite64 fails to support
large files in 32-bit application)
has caused the Debian Bug report #559376,
regarding pwrite64 fails to support large files in 32-bit application
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
559376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559376
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libc6
Version: 2.7-18
A Ubuntu user of GraphicsMagick reported a problem with large files.
I tested under 32-bit i386 Debian Lenny and was able to reproduce the
problem. What I found is that pwrite64 64-bit file offset of
2147486400 (just under 2GB, 2147483648) and writing across the 2GB
boundary has apparently been transformed to 18446744071562070720 in
the system call, which subsequently fails, returning -1 with
errno=EINVAL. If I configure the software to use fseeko/write rather
than pwrite (using same offsets and access pattern) then there is no
problem.
Here are some strace traces. The 'write' is from fprintf stderr,
printing the original argument values.
write(2, "pwrite file=4, io_buff_address=0x"..., 96pwrite file=4,
io_buff_address=0x0xb77e1008, requested_io_size=150400, io_file_offset=648675200
) = 96
pwrite64(4,
"\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377"...,
150400, 648675200) = 150400
write(2, "pwrite file=4, io_buff_address=0x"..., 96pwrite file=4,
io_buff_address=0x0xb7805b88, requested_io_size=37600, io_file_offset=2147448800
) = 96
pwrite64(4,
"\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1"..., 37600,
2147448800) = 37600
write(2, "pwrite file=4, io_buff_address=0x"..., 96pwrite file=4,
io_buff_address=0x0xb77e1008, requested_io_size=150400, io_file_offset=648825600
) = 96
pwrite64(4,
"\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377\377\377\377\377\377\0\0\377"...,
150400, 648825600) = 150400
write(2, "pwrite file=4, io_buff_address=0x"..., 96pwrite file=4,
io_buff_address=0x0xb7805b88, requested_io_size=37600, io_file_offset=2147486400
) = 96
pwrite64(4,
"\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1\0\1"..., 37600,
18446744071562070720) = -1 EINVAL (Invalid argument)
The same code works fine on 32 bit Solaris, FreeBSD, and OS-X. It
also works fine on 64-bit AMD64 Debian Lenny.
Thanks,
Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
--- End Message ---
--- Begin Message ---
On Fri, Dec 04, 2009 at 05:17:45PM -0600, Bob Friesenhahn wrote:
> I think that this bug report is bogus. The pread/pwrite interfaces
> do work with
OK, closing the bug.
> #define _XOPEN_SOURCE 500
>
> GraphicsMagick has not been definining _XOPEN_SOURCE since this
> breaks compilation on many systems. Instead it has been providing
> its own prototypes for pread and pwrite with this form:
>
> ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
> ssize_t pwrite(int fildes, const void *buf, size_t nbyte, off_t offset);
I confirm this is wrong it should have been off64_t.
> which should normally be sufficient, but apparently not sufficient
> for Linux.
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
[email protected] http://www.aurel32.net
--- End Message ---
