Bug#34953: marked as done (The elm problem)
Your message dated Tue, 11 May 1999 01:05:22 -0700
with message-id <v04204e05b35d94ca397b@[206.163.71.146]>
and subject line Forgot to close these
has caused the attached bug report 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 I'm
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Ian Jackson
(administrator, Debian bugs database)
Received: (at submit) by bugs.debian.org; 23 Mar 1999 16:48:25 +0000
Received: (qmail 12710 invoked from network); 23 Mar 1999 16:48:22 -0000
Received: from smtp1.xs4all.nl (194.109.6.51)
by master.debian.org with SMTP; 23 Mar 1999 16:48:22 -0000
Received: from night (harte.xs4all.nl [194.109.63.66])
by smtp1.xs4all.nl (8.8.8/8.8.8) with ESMTP id RAA00909
for <submit@bugs.debian.org>; Tue, 23 Mar 1999 17:48:14 +0100 (CET)
Received: from dark by night with local (Exim 2.11 #1 (Debian))
id 10PUNh-0002VH-00; Tue, 23 Mar 1999 17:50:21 +0100
Subject: The elm problem
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
Reply to: