- Subject: Digested Articles
- From: Various
- Date: Thu Mar 25 08:06:08 1999
Topics:
Bug#34953: The elm problem
Bug#34953: Possible fix for this problem
Bug#35023: libc6: C++ incompatibility bug
----------------------------------------------------------------------
Date: Tue, 23 Mar 1999 17:50:21 +0100 (CET)
From: Richard Braakman <dark@xs4all.nl>
To: submit@bugs.debian.org
Subject: Bug#34953: The elm problem
Message-Id: <E10PUNh-0002VH-00@night>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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
- -
To UNSUBSCRIBE, email to debian-glibc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------------------------------
Date: Thu, 25 Mar 1999 02:09:02 +0100 (CET)
From: Richard Braakman <dark@xs4all.nl>
To: 34953@bugs.debian.org
Subject: Bug#34953: Possible fix for this problem
Message-Id: <E10Pydq-0004Zs-00@night>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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
------------------------------
Date: Wed, 24 Mar 1999 17:47:54 -0700
From: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>
To: submit@bugs.debian.org
Subject: Bug#35023: libc6: C++ incompatibility bug
Message-Id: <E10PyJO-0000LS-00@Wakko.deltatee.com>
Package: libc6
Version: 2.1.1-0.1
I have created a test case derived from the code in APT that when runs on
glibc 2.1 without recompilation fails. The test case is very simple:
#include <iostream>
#include <fstream>
void die(const char *S)
{
cerr << S << endl;
exit(1);
}
int main(int argc,const char *argv[])
{
ifstream F(argv[1],ios::in | ios::nocreate);
if (!F != 0)
die("!F #1");
streampos Off = F.tellg();
if (!F != 0)
die("!F #2");
return 0;
}
Results on glibc2.1 using 2.0 compiled binary..
[..]
open("/var/state/apt/lists/mirror_debian_dists_potato_main_binary-i386_Packages",O_RDONLY)=3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
_llseek(3, 4294967296, 0xbffffb10, 0x4016521c /* SEEK_??? */) = -1 EINVAL
(Invalid argument)
write(2, "!F #2", 5!F #2) = 5
write(2, "\n", 1
) = 1
_exit(1) = ?
Results on glibc2.1 using a 2.1 compiled binary..
[..]
open("/var/state/apt/lists/mirror_debian_dists_potato_main_binary-i386_Packages",O_RDONLY|0x8000)=3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40014000
_llseek(3, 0, {0}, SEEK_CUR) = 0
close(3) = 0
munmap(0x40014000, 4096) = 0
_exit(0) = ?
The key difference appears to be in how llseek is called. I belive that if
this is fixed APT 0.1.10 will run without recompilation on glibc2.1.
This bug may be related to #34953
Jason
- -
To UNSUBSCRIBE, email to debian-glibc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------------------------------
End of forwardpuBQtf Digest
***************************