[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#559376: marked as done (pwrite64 fails to support large files in 32-bit application)

Your message dated Mon, 7 Dec 2009 01:28:46 +0100
with message-id <20091207002846.GA17645@volta.aurel32.net>
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 owner@bugs.debian.org
immediately.)


-- 
559376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559376
Debian Bug Tracking System
Contact owner@bugs.debian.org 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
bfriesen@simple.dallas.tx.us, 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
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: