[Cooker] Backward binary compatbility broken with glibc 2.3.2

[Richard Bass]

Package: glibc
Version: 2.3.2-2
(Sorry - the above mini-header was for the Debian bug tracking system).

To the glibc maintainers, et al:

I tried to access gnats at http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl
but there was no response, so I am emailing this bug report.
We have a chrooted build environment which we have been using over the
last couple of years that is based on the RedHat 5.2 distribution.  This
shipped with glibc-2.0.7-29 and gcc-2.7.2.3-14.  Programs we have built
in this environment have successfully run on virtually every Gnu/Linux
distribution we have ever come across.  Unfortunately, glibc 2.3.2 has
broken binary compatibility with these programs.  I include below
the source of a program which when compiled in this build environment,
dumps core when dynamically linked against glibc 2.3.2.  I have
experienced this on Debian SID and Mandrake 9.2 beta2, both of
which include versions of glibc 2.3.2.  Let me also mention that
all PRIOR versions of glibc have worked just fine, so something must
have gotten broken in 2.3.2.
Here's the program:
---------------------------------------------------
#include <stdio.h>
main()
{
        FILE *fp;
        fp = fopen("/etc/group", "r");
        if (fp == NULL) {
                printf("Couldn't open /etc/group\n");
                exit(1);
        }
        fseek(fp, 0L, 2);
        printf("Apparently no coredump\n");
        exit(0);
}
---------------------------------------------------

Note that /etc/group is just a random file that one expects to
be around and readable.  The fseek() is what dumps core.
I spent a little time debugging this using the debian glibc 2.3.2
sources.  The problem is that the fopen() that gets used is the
one in libio/oldiofopen.c.  This file defines _IO_USE_OLD_IO_FILE
so that the malloc() that is done in _IO_old_fopen() is for
an _IO_FILE structure that does not include the _IO_FILE_complete
elements, most specifically the _mode field.  However, the fseek()
that gets used ultimately gets into _IO_seekoff_unlocked() in
ioseekoff.c.  In this case the _IO_fwide() tests access the _mode
field which actually is an offset associated with a lock structure,
and, well, let's just say it doesn't go well.  _IO_have_wbackup()
dereferences the _wide_data field which is NULL and *pow* coredump.
I am not sure how all this is supposed to be handled, but I figure with
this much information, the glibc experts will know.
If it is inconvenient to dig up an old glibc to compile a test
program with, you can download one from
    ftp://ftp.netraverse.com/pub/glibc-bug
I would have provided one as an attachment, but I suspect attachments
are stripped from list email.
Oh... one other thing:  We have decided to update our build environment
to work around the problem.  However, I wanted to pass this on because I
am sure there are other binaries hanging around out there that people
have not recompiled in a long time.
Thanks,

Richard <rwb>

--
Richard W. Bass
Systems Software Architect
NeTraverse, Inc.