public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/11865] SegFault in libc_print_version on program start Date: Mon, 30 Jun 2014 17:27:00 -0000 [thread overview] Message-ID: <bug-11865-131-Aka02CjQAb@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-11865-131@http.sourceware.org/bugzilla/> 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.
next parent reply other threads:[~2014-06-30 17:27 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-11865-131@http.sourceware.org/bugzilla/> 2014-06-30 17:27 ` fweimer at redhat dot com [this message] 2010-07-31 17:27 [Bug libc/11865] New: " beartham at gmail dot com 2010-07-31 17:38 ` [Bug libc/11865] " beartham at gmail dot com 2010-07-31 18:17 ` drepper at redhat dot com 2010-07-31 21:22 ` drepper at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-11865-131-Aka02CjQAb@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).