I noticied recently that starting from some recent glibc
version, all {file,text,shell}utils (aka fetish) started
to crash at exit, in __fpending() routine. After some
attempts to discover the problem, I found that any package
compiled with old version of glibc runs just fine. I have
fileutils-4.1-1 rpm here, it was compiled against glibc-2.2-10.
So this looks like a glibc problem.
All fetish programs uses the following construct:
atexit(close_stdout);
where the close_stdout() routine defined as follows:
close_stdout_status (int status)
{
int e = ferror (stdout) ? 0 : -1;
if (__fpending (stdout) == 0)
return;
if (fclose (stdout) != 0)
e = errno;
if (0 <= e)
{
char const *write_error = _("write error");
if (file_name)
error (status, e, "%s: %s", quotearg_colon (file_name), write_error);
else
error (status, e, "%s", write_error);
}
}
All the programs crashes in a call to __fpending(), that itself
defined as follows (in glibc, libio/__fpending.c):
size_t
__fpending (FILE *fp)
{
if (fp->_mode > 0)
return fp->_wide_data->_IO_write_ptr - fp->_wide_data->_IO_write_base;
else
return fp->_IO_write_ptr - fp->_IO_write_base;
}
I was unable to trace this routine: gdb shows a garbaged stack here
(e.g. __fpending was called from strcpy).
All packages was recompiled here by gcc-2.96-85 or 2.96-97 (I prefer to
use source rpms). Glibc was compiled with linux-2.2.x support only
(using headers from 2.2.18), and I commented out generating of special
2.4.x i686-optimized version in glibc.spec. Other than that, no changes
that can be related to the problem was made. Similar results shows all
machines here, with different CPUs and thus with different glibc-ARCH
installed (all i386, i586 and i686).
Looking to current rawhide it seems that this packages was not rebuilt
with latest glibc as well, so them should work just fine too. I don't
know if those packages will break if recompiled with current glibc on
a standard RedHat machine.
Can someone point me to the right direction?
Thank you.
Regards,
Michael.
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
