Bug 82933 - Segmentation fault in freopen() on Redhat 8 with GCC 2.95.3
Summary: Segmentation fault in freopen() on Redhat 8 with GCC 2.95.3
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-28 16:52 UTC by Philip George
Modified: 2016-11-24 14:49 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Philip George 2003-01-28 16:52:46 UTC
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 14:57:52 UTC
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 16:08:04 UTC
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 16:10:36 UTC
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.