Fwd: Bug#34953: Possible fix for this problem

[Joel Klecker <espy@debian.org>]

[ Please keep 34953-forwarded@bugs.debian.org in the cc list so the 
Debian Bug Tracking System can record replies. ]

There are two messages included here, one includes a test case, and 
the other a suggested fix.

--- begin forwarded text
Envelope-to: jk@espy.org
Delivered-To: espy@debian.org
Subject: Bug#34953: Possible fix for this problem
Reply-To: Richard Braakman <dark@xs4all.nl>, 34953@bugs.debian.org
Resent-From: Richard Braakman <dark@xs4all.nl>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Joel Klecker and others <debian-glibc@lists.debian.org>
Resent-Date: Thu, 25 Mar 1999 01:18:03 GMT
X-Debian-PR-Message: report 34953
X-Debian-PR-Package: libc6
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
To: 34953@bugs.debian.org
Date: Thu, 25 Mar 1999 02:09:02 +0100 (CET)
From: Richard Braakman <dark@xs4all.nl>
X-Mailing-List: <debian-glibc@lists.debian.org> archive/latest/236
X-Loop: debian-glibc@lists.debian.org
Resent-Sender: debian-glibc-request@lists.debian.org
Status:

I think that in libio/oldfileops.c, line 411 (_IO_old_file_sync),
delta should be type _IO_ssize_t, just like it is in _IO_new_file_sync.
It makes sense for delta to be a signed type, because of the
way it is used:

  delta = fp->_IO_read_ptr - fp->_IO_read_end;

read_ptr is supposed to be <= read_end, so delta is expected to be
negative.  Now that it gets passed to a seek function that takes
64-bit offsets, the distinction becomes important.

Jason Guntorpe told me that this is likely to fix the apt problem as well.
(He reduced apt to a very similar test case).

Richard Braakman


--
To UNSUBSCRIBE, email to debian-glibc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--- end forwarded text

--- begin forwarded text
Subject: Bug#34953: The elm problem
Reply-To: Richard Braakman <dark@xs4all.nl>, 34953@bugs.debian.org
Resent-From: Richard Braakman <dark@xs4all.nl>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Joel Klecker and others <debian-glibc@lists.debian.org>
Resent-Date: Tue, 23 Mar 1999 17:03:01 GMT
Resent-Message-ID: <handler.34953.B.92220770512714@bugs.debian.org>
Resent-Sender: iwj@debian.org
X-Debian-PR-Message: report 34953
X-Debian-PR-Package: libc6
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
Received: via spool by bugs@bugs.debian.org id=B.92220770512714
          (code B ref -1); Tue, 23 Mar 1999 17:03:01 GMT
To: submit@bugs.debian.org
Date: Tue, 23 Mar 1999 17:50:21 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL52 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E10PUNh-0002VH-00@night>
From: Richard Braakman <dark@xs4all.nl>

Package: libc6
Version: 2.1.1-0.1
Severity: important

I've spent the day figuring out what goes wrong with a glib2.0-compiled
elm on a glibc2.1 system.  I didn't find the bug, but I managed to
distill a simple test case:

#include <stdio.h>

void bail(char *where) {
    perror(where);
    exit(1);
}

int main(void) {
    FILE *test;

    if ((test = fopen("seektestfile", "w+")) == NULL)  bail("fopen");
    if (fputs("Test data", test) < 0)  bail("fputs");
    if (fseek(test, 0, 2) != 0)  bail("fseek 1");
    if (fseek(test, 0, 0) != 0)  bail("fseek 2");
    if (fflush(test) != 0)  bail("fflush");
    exit(0);
}

If this program is compiled on a glibc2.0 system and run on a glibc2.1
system, the fflush call will fail with EINVAL.  If the program is
compiled on a glibc2.1 system and run on a glibc2.1 system, it works
fine.  The reason can be found in the relevant part of the straces.

Trace of glibc2.1-compiled (good) version:
[...]
open("seektestfile", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4
fstat(4, {st_mode=S_ISVTX|0502, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x40014000
write(4, "Test data", 9)                = 9
fstat(4, {st_mode=S_ISVTX|0502, st_size=0, ...}) = 0
_llseek(4, 0, {0}, SEEK_SET)            = 0
read(4, "Test data", 4096)              = 9
_llseek(4, 9, {9}, SEEK_SET)            = 0
_llseek(4, -9, {0}, SEEK_CUR)           = 0
[...]

Trace of glibc2.0-compiled version:
[...]
open("seektestfile", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4
fstat(4, {st_mode=S_ISVTX|0502, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x400140
00
write(4, "Test data", 9)                = 9
fstat(4, {st_mode=S_ISVTX|0502, st_size=0, ...}) = 0
_llseek(4, 0, {0}, SEEK_SET)            = 0
read(4, "Test data", 4096)              = 9
_llseek(4, 9, {9}, SEEK_SET)            = 0
_llseek(4, 4294967287, 0xbffff9e8, SEEK_CUR) = -1 EINVAL (Invalid argument)

In both cases the final line is from fflush (not from fseek, which simply
sets some pointers and does not invoke a system call).  The number
4294967287 is exactly -9 when interpreted as an unsigned long, so
I expect that the problem is somewhere in the big-files handling.

I failed to track the problem down inside glibc, but I hope that this
test case helps.

Richard Braakman
--- end forwarded text
--
Joel Klecker (aka Espy)                     <URL:http://web.espy.org/>
<URL:mailto:jk@espy.org>                  <URL:mailto:espy@debian.org>