Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2003-01-29 16:10:36 UTC


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.