[Bug libc/11865] SegFault in libc_print_version on program start

[Bug libc/11865] SegFault in libc_print_version on program start

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11865

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

--- Comment #5 from Joseph Thames <beartham at gmail dot com> ---
Subject: Re:  SegFault in libc_print_version on program start

We don't have the luxury of a knowledgeable Linux SysAdmin. We are
just trying to get a very important Fortran-based product to work
again. It is a very-high level optimization modeling language which
generates Fortran API code invoking a large library of "built-in"
numerical solvers. The original DOS and Suse 9.0 version was F77 (g77)
static libraries. The Fedora 8 version was F95 (gfortran), also with
static libraries.

The original problem we ran into was that the gcc linker pass-through
-Wl,--start-group ... -Wl,--end-group for static linking of multiple
interdependent archives no longer works for current gcc versions. So
we had to use the "-c" compilation option and a separate ld command
line.

We finally got some test-applications to load "successfully" from the
static library group (including the DISLIN graphics library from the
Max Planck Institute, which is not in any of the Redhat or Debian
based repos). So far so good.

But when we tried to execute them, we got this cryptic "bad ELF
interpreter, no such file or directory" and "success" messages,
without any reference to the missing file name.  This was on Kubuntu
8.04 and 9.10 distros. This was when we changed over to the (hopefully
more stable) CentOS 5.5 platform. Here we got the same message, but
this time identifying the missing file as libc.so.1.

Since all of this was static linking, we didn't expect there to be a
reference to an SO library. But since there are a few C routines in
our solver libraries (which apparently referenced libc.a before), we
reasoned  that we were missing the "standard C library", which on the
CentOS 5.5 distro was /lib/libc-2.5.so., on the Ku8.04 distro was
/lib/libc-2.7.so, and on Ku9.10 was /lib/libc-2.10.so, all of which
were apparently built from glibc sources.

So we created symlinks to the standard C libraries from the missing
reference libc.so.1, hoping to get the test-apps to at least start
execution so that we could use gdb and Valgrind to debug them. This is
when we got the segfault in the __libc_print_version routine. This
made some sense to us as to why the libc.so.1 ref was in our linked
executable in the first place---to print out the GNU banner prior to
executing the first executable Fortran statement. Thus we thought we
were on the right track and had uncovered a glibc bug. We found other
evidence of similar segfaults from Googling the web.

Now you tell us that libc.so.1 has nothing to do with glibc.

Ok, where do we go from here? If we had known who to ask we would have
asked about this, but we have not had much luck lately with this
"forums shotgun" approach. It seems to just open up more blind alleys
to follow.

Would you be willing to be our consultant in matters like this?


On Sat, Jul 31, 2010 at 3:22 PM, drepper at redhat dot com
<sourceware-bugzilla@sourceware.org> wrote:
>
> ------- Additional Comments From beartham at gmail dot com  2010-07-31 21:15 -------
> Subject: Re:  SegFault in libc_print_version on program start
>
> On Sat, Jul 31, 2010 at 3:11 PM, Joseph Thames <beartham@gmail.com> wrote:
>>
>> Originally this problem was showing up following static linking of a fortran program (two cases, one using a g77 compiler and the other using the gfortran compiler) as a "bad ELF interpreter, no such file or directory" message, followed by a "success" message(???). We determined that the file it was looking for was libc.so.1.  So I symbolic linked /usr/lib/libc.so.1 to /lib/libc-2.5.so, and when I reran the executable, I got the segfault in version.c, when it was trying to print the GNU version banner. So it is definitely a problem in the C library.
>>
>> I had used the small Fortran program in place of the large Fortran program that originally produced the segfault, to eliminate the possibility that it might have been the linking of the large program from a set of external libraries (overwriting a pointer, etc.) that caused the problem. The little Fortran program did not link anything from these libraries, but it produced the segfault.
>>
>> So far I have not been able to get any Fortran programs to execute after loading, because of this libc segfault.  I have downloaded glibc source and have commented out the call to _libc_print_version in version.c.  I'm getting ready to recompile and test this modified glibc, so I can get my Fortran programs to execute. I will let you know the results.
>>
>> Best regards,
>>
>> Joseph Thames
>>
>> On Sat, Jul 31, 2010 at 12:17 PM, drepper at redhat dot com <sourceware-bugzilla@sourceware.org> wrote:
>>>
>>> ------- Additional Comments From drepper at redhat dot com  2010-07-31 18:17 -------
>>> If you cannot reproduce a problem with a valid C program it is no problem in the
>>> C library.  Don't submit Fortran code.
>>>
>>> --
>>>           What    |Removed                     |Added
>>> ----------------------------------------------------------------------------
>>>             Status|NEW                         |WAITING
>>>
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=11865
>>>
>>> ------- You are receiving this mail because: -------
>>> You reported the bug, or are watching the reporter.
>>
>>
>>
>> --
>> Joseph 'Bear' Thames
>> MetaCalculus, LLC and Meta Science Foundation
>> (505) 977-9024 - Cell Phone
>> beartham@gmail.com
>
>
>
> --
> Joseph 'Bear' Thames
> MetaCalculus, LLC and Meta Science Foundation
> (505) 977-9024 - Cell Phone
> beartham@gmail.com
>
> ------- Additional Comments From drepper at redhat dot com  2010-07-31 21:22 -------
>> Originally this problem was showing up following static linking of a fortran
> program
>> (two cases, one using a g77 compiler and the other using the gfortran
> compiler) as a
>> "bad ELF interpreter, no such file or directory" message, followed by a "success"
>> message(???). We determined that the file it was looking for was libc.so.1.  So I
>> symbolic linked /usr/lib/libc.so.1 to /lib/libc-2.5.so, and when I reran the
>> executable, I got the segfault in version.c, when it was trying to print the GNU
>> version banner. So it is definitely a problem in the C library.
>>
>> I had used the small Fortran program in place of the large Fortran program that
>> originally produced the segfault, to eliminate the possibility that it might
> have been
>> the linking of the large program from a set of external libraries (overwriting a
>> pointer, etc.) that caused the problem. The little Fortran program did not link
>> anything from these libraries, but it produced the segfault.
>>
>> So far I have not been able to get any Fortran programs to execute after loading,
>> because of this libc segfault.  I have downloaded glibc source and have
> commented out
>> the call to _libc_print_version in version.c.  I'm getting ready to recompile
> and test
>> this modified glibc, so I can get my Fortran programs to execute. I will let
> you know
>> the results.
>
>
> Obviously broken environment coupled with completely incorrect sysadmin work.
> libc.so.1 has nothing whatsoever to do with glibc so what do you ecpect?
>
> --
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|WAITING                     |RESOLVED
>         Resolution|                            |INVALID
>
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=11865
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>





-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-24829-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Jun 30 17:28:04 2014
Return-Path: <glibc-bugs-return-24829-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 32276 invoked by alias); 30 Jun 2014 17:28:03 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 31614 invoked by uid 48); 30 Jun 2014 17:27:55 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug regex/11857] Missing documentation in regex.h
Date: Mon, 30 Jun 2014 17:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: regex
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: flagtypes.name
Message-ID: <bug-11857-131-q2e7eIfzT4@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-11857-131@http.sourceware.org/bugzilla/>
References: <bug-11857-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg02205.txt.bz2
Content-length: 378

https://sourceware.org/bugzilla/show_bug.cgi?id\x11857

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11865] SegFault in libc_print_version on program start

[drepper at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4577 bytes --]


------- Additional Comments From beartham at gmail dot com  2010-07-31 21:15 -------
Subject: Re:  SegFault in libc_print_version on program start

On Sat, Jul 31, 2010 at 3:11 PM, Joseph Thames <beartham@gmail.com> wrote:
>
> Originally this problem was showing up following static linking of a fortran program (two cases, one using a g77 compiler and the other using the gfortran compiler) as a "bad ELF interpreter, no such file or directory" message, followed by a "success" message(???). We determined that the file it was looking for was libc.so.1.  So I symbolic linked /usr/lib/libc.so.1 to /lib/libc-2.5.so, and when I reran the executable, I got the segfault in version.c, when it was trying to print the GNU version banner. So it is definitely a problem in the C library.
>
> I had used the small Fortran program in place of the large Fortran program that originally produced the segfault, to eliminate the possibility that it might have been the linking of the large program from a set of external libraries (overwriting a pointer, etc.) that caused the problem. The little Fortran program did not link anything from these libraries, but it produced the segfault.
>
> So far I have not been able to get any Fortran programs to execute after loading, because of this libc segfault.  I have downloaded glibc source and have commented out the call to _libc_print_version in version.c.  I'm getting ready to recompile and test this modified glibc, so I can get my Fortran programs to execute. I will let you know the results.
>
> Best regards,
>
> Joseph Thames
>
> On Sat, Jul 31, 2010 at 12:17 PM, drepper at redhat dot com <sourceware-bugzilla@sourceware.org> wrote:
>>
>> ------- Additional Comments From drepper at redhat dot com  2010-07-31 18:17 -------
>> If you cannot reproduce a problem with a valid C program it is no problem in the
>> C library.  Don't submit Fortran code.
>>
>> --
>>           What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>             Status|NEW                         |WAITING
>>
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=11865
>>
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.
>
>
>
> --
> Joseph 'Bear' Thames
> MetaCalculus, LLC and Meta Science Foundation
> (505) 977-9024 - Cell Phone
> beartham@gmail.com



--
Joseph 'Bear' Thames
MetaCalculus, LLC and Meta Science Foundation
(505) 977-9024 - Cell Phone
beartham@gmail.com

------- Additional Comments From drepper at redhat dot com  2010-07-31 21:22 -------
> Originally this problem was showing up following static linking of a fortran
program
> (two cases, one using a g77 compiler and the other using the gfortran
compiler) as a
> "bad ELF interpreter, no such file or directory" message, followed by a "success"
> message(???). We determined that the file it was looking for was libc.so.1.  So I
> symbolic linked /usr/lib/libc.so.1 to /lib/libc-2.5.so, and when I reran the
> executable, I got the segfault in version.c, when it was trying to print the GNU
> version banner. So it is definitely a problem in the C library.
>
> I had used the small Fortran program in place of the large Fortran program that
> originally produced the segfault, to eliminate the possibility that it might
have been
> the linking of the large program from a set of external libraries (overwriting a
> pointer, etc.) that caused the problem. The little Fortran program did not link
> anything from these libraries, but it produced the segfault.
>
> So far I have not been able to get any Fortran programs to execute after loading,
> because of this libc segfault.  I have downloaded glibc source and have
commented out
> the call to _libc_print_version in version.c.  I'm getting ready to recompile
and test
> this modified glibc, so I can get my Fortran programs to execute. I will let
you know
> the results.


Obviously broken environment coupled with completely incorrect sysadmin work. 
libc.so.1 has nothing whatsoever to do with glibc so what do you ecpect?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=11865

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11865] SegFault in libc_print_version on program start

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-07-31 18:17 -------
If you cannot reproduce a problem with a valid C program it is no problem in the
C library.  Don't submit Fortran code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=11865

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11865] SegFault in libc_print_version on program start

[beartham at gmail dot com]

------- Additional Comments From beartham at gmail dot com  2010-07-31 17:37 -------
To reproduce the bug, try this trivial gfortran program (in the middle of the
text below):

    1             PROGRAM FC000000                                              
    2             IMPLICIT REAL*8 (A-H,O-Z)                                     
    3             REAL RTIMES(2),RSTART,REND                                    
    4             RSTART=1000.0                                                 
    5             REND=2000.0                                                   
    6             PRINT 999, REND-RSTART                                        
    7        999  FORMAT(" ELAPSED TIME = ",F7.2," SECONDS")                    
    8             END                          

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11865

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.