Bug 82933 - Segmentation fault in freopen() on Redhat 8 with GCC 2.95.3
Segmentation fault in freopen() on Redhat 8 with GCC 2.95.3
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
i686 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-28 11:52 EST by Philip George
Modified: 2016-11-24 09:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-29 11:10:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Philip George 2003-01-28 11:52:46 EST
Description of problem
======================
I have compiled and installed binutils 2.12 and GCC 2.95.3 on a Redhat 8.0 
machine (bootstrapping from GCC3.2).

I would like to run this simple program:

// phil.cc
#include <stdio.h>
int main(void) {
    FILE *fr=freopen("blib","r",stdin);
    printf("Success\n");
    return 1;
}

But this happens:
% g++ phil.cc -o phil
% phil
Segmentation fault

It works fine with exactly the same binutils & GCC on Redhat 6.2, so why the 
seg fault in RH8?

We are using glibc 2.2.93-5.

Ldd reveals this...

% ldd phil
	libstdc++-libc6.3-2.so.3 =>
/usr/installed/gcc2.95.3/lib/libstdc++-libc6.3-2.so.3 (0x40013000)
	libm.so.6 => /lib/i686/libm.so.6 (0x40070000)
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

If I instead try to build it as a C program, ie.
% gcc phil.cc -o phil
...  then it works fine.

What on earth could be going wrong?  I'd thought that perhaps the
libraries might be out of sync but I can't think how or why that would be the 
case.  So I'm sure it must be a problem with glibc.

On the Redhat 8 box we also have a GCC 3.2 compiler installed.  But I've made 
sure that the GCC2.95.3 installation directory appears at the beginning of my 
$PATH and $LD_LIBRARY_PATH to make sure it's picking up the correct one.

(FYI, ldd on the working 'gcc'-compiled version gives...
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
)

Version-Release number of selected component (if applicable)
============================================================
glibc 2.2.93-5

How reproducible
================
Every time

Steps to Reproduce
==================
1. Take a clean Redhat 8.0 install (unpatched)
2. Using GCC 3.2, build & install binutils 2.12 and then GCC 2.95.3.
GCC config pars are --prefix=<inst dir> --enable-threads --enable-shared --
enable-cpp --enable-languages=c++ --with-gnu-as --with-gnu-ld --with-dwarf2.
3. Setting PATH and LD_LIBRARY_PATH to use the new binutils and GCC, try to 
build this:
// phil.cc
#include <stdio.h>
int main(void) {
    FILE *fr=freopen("blib","r",stdin);
    printf("Success\n");
    return 1;
}
using...
g++ phil.cc -o phil
4.  Try to run 'phil'.  Seg fault occurs.
    
Actual results
==============
Seg fault occurs

Expected results
================
Program should exit with no errors.  (It works correctly on RH6.2, or building 
it using gcc, rather than g++).

Additional info
===============
We are actually trying to build ACE+TAO 5.2.  This error cropped up because the 
ACE+TAO build process tries to build & run gperf, which in turn tries to use 
freopen() in the same way.  Hence ACE+TAO 5.2 would not build.
Comment 1 Jakub Jelinek 2003-01-29 09:57:52 EST
Were you building stock 2.95.3 or have you patched it?
Stock 2.95.3 doesn't work with glibc 2.2+.
Comment 2 Philip George 2003-01-29 11:08:04 EST
It's plain unpatched 2.95.3, built from scratch on RH8.   I didn't realise it 
was not compatible with GLIBC 2.2+.  Why is it not compatible?  Is there a set 
of patches which will make it work?
Comment 3 Jakub Jelinek 2003-01-29 11:10:36 EST
If you build it on pre-glibc-2.2, it should work with 2.2+ glibc, but it will
not compile properly unpatched.
I think the patches are on gcc-2_95_branch, but am not sure about that.

Note You need to log in before you can comment on or make changes to this bug.