Below is the first half of this bug report, taken from the Kubuntu 9.10 host, an HP dv6000 laptop with an Intel 32-bit core-duo processor. The second half follows, desribing the same problem in a CentOS 5.5 VMware virtual appliance running on the same hardware. Its user is "Tosva Unitus", a pseudonym shared by users of this virtual machine. I have encountered this bug on i386 versions of Kubuntu 8.04 and CentOS 5.5 with glibc 2.5, in statically linked g77 and gfortran programs and on Kubuntu 9.10 with glibc 2.10 with dynamically linked gfortran programs. The programs themselves have not been altered in years, having successfully run many times on DOS using 32-bit Lahey Fortran, and more recently on x86 Suse 9.0 in g77 and x86 Fedora 8 in gfortran. These programs have been linked from an external library of solution algorithms. In all cases except the final (Kubuntu 9.10), these libraries were static archives, in which case libc.so.1 (the source of the segfault) was the only dynamic linkage. A symbolic link from /usr/lib/libc.so.1 to the /lib resident libc-2.5.so or libc-2.10.so was defined. The following is a the latest attempt, on the Kubuntu 9.10 host using gdb: bear@nomad:/tmp/MC7B/bear/default/woodzh$ bear@nomad:/tmp/MC7B/bear/default/woodzh$ ./woodzh Segmentation fault bear@nomad:/tmp/MC7B/bear/default/woodzh$ gdb woodzh GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/MC7B/bear/default/woodzh/woodzh...done. (gdb) l 1 PROGRAM FC000000 2 IMPLICIT REAL*8 (A-H,O-Z) 3 COMMON /FC3000/MPAD,MAXB,IBUC(2,5000) 4 REAL*8 DBUC(5000) 5 CHARACTER*4 CBUC(2,5000) 6 EQUIVALENCE (IBUC(1,1),DBUC(1)) 7 EQUIVALENCE (CBUC(1,1),IBUC(1,1)) 8 REAL RTIMES(2),RSTART,REND 9 COMMON /FC3007/ JPAD,MVDT,NVDT,KVDT,VDT(2,3000) 10 COMMON/FC3001/NUN(23),NGRAFS,KDEBUG,INITA,INITB,INITC,INITD (gdb) l 11 CALL DTIME(RTIMES,RSTART) 12 MAXB=5000 13 MVDT=3000 14 CALL FC0001(3000,"WOODZH",1) 15 CALL WOODZH 16 CALL FC0391(-1,"CLOSE LUSCTOC") 17 CALL FC0392(-1,"CLOSE LUPRTOC") 18 CALL FCLTERM 19 CALL DTIME(RTIMES,REND) 20 PRINT 999, REND-RSTART (gdb) b 11 Breakpoint 1 at 0x804811d: file woodzh.for, line 11. (gdb) run Starting program: /tmp/MC7B/bear/default/woodzh/woodzh warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x0060bd90 in write () from /usr/lib/libc.so.1 (gdb) bt #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) #0 0x0060bd90 in write () from /usr/lib/libc.so.1 #1 0x00563ca0 in ?? () from /usr/lib/libc.so.1 (gdb) q A debugging session is active. Inferior 1 [process 29893] will be killed. Quit anyway? (y or n) y bear@nomad:/tmp/MC7B/bear/default/woodzh$ Next, I processed this executable with Valgrind: bear@nomad:/tmp/MC7B/bear/default/woodzh$ bear@nomad:/tmp/MC7B/bear/default/woodzh$ valgrind -v ./woodzh ==29896== Memcheck, a memory error detector ==29896== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==29896== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==29896== Command: ./woodzh ==29896== --29896-- Valgrind options: --29896-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --29896-- -v --29896-- Contents of /proc/version: --29896-- Linux version 2.6.31-19-generic (buildd@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010 --29896-- Arch and hwcaps: X86, x86-sse1-sse2 --29896-- Page sizes: currently 4096, max supported 4096 --29896-- Valgrind library directory: /usr/lib/valgrind --29896-- Reading syms from /lib/libc-2.10.1.so (0x4000000) --29896-- Reading debug info from /lib/libc-2.10.1.so .. --29896-- .. CRC mismatch (computed b45cc142 wanted d58c444b) --29896-- Reading debug info from /usr/lib/debug/lib/libc-2.10.1.so .. --29896-- Reading syms from /tmp/MC7B/bear/default/woodzh/woodzh (0x8048000) --29896-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000) --29896-- object doesn't have a dynamic symbol table --29896-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp --29896-- Reading suppressions file: /usr/lib/valgrind/default.supp ==29896== ==29896== Process terminating with default action of signal 11 (SIGSEGV) ==29896== General Protection Fault ==29896== at 0x40BED90: write (in /lib/libc-2.10.1.so) ==29896== by 0x4016CC6: __libc_main (version.c:73) ==29896== ==29896== HEAP SUMMARY: ==29896== in use at exit: 0 bytes in 0 blocks ==29896== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==29896== ==29896== All heap blocks were freed -- no leaks are possible ==29896== ==29896== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==29896== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault Here is another run of gdb where I printed the register contents: bear@nomad:/tmp/MC7B/bear/default/woodzh$ bear@nomad:/tmp/MC7B/bear/default/woodzh$ gdb woodzh GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/MC7B/bear/default/woodzh/woodzh...done. (gdb) l 1 PROGRAM FC000000 2 IMPLICIT REAL*8 (A-H,O-Z) 3 COMMON /FC3000/MPAD,MAXB,IBUC(2,5000) 4 REAL*8 DBUC(5000) 5 CHARACTER*4 CBUC(2,5000) 6 EQUIVALENCE (IBUC(1,1),DBUC(1)) 7 EQUIVALENCE (CBUC(1,1),IBUC(1,1)) 8 REAL RTIMES(2),RSTART,REND 9 COMMON /FC3007/ JPAD,MVDT,NVDT,KVDT,VDT(2,3000) 10 COMMON/FC3001/NUN(23),NGRAFS,KDEBUG,INITA,INITB,INITC,INITD (gdb) l 11 CALL DTIME(RTIMES,RSTART) 12 MAXB=5000 13 MVDT=3000 14 CALL FC0001(3000,"WOODZH",1) 15 CALL WOODZH 16 CALL FC0391(-1,"CLOSE LUSCTOC") 17 CALL FC0392(-1,"CLOSE LUPRTOC") 18 CALL FCLTERM 19 CALL DTIME(RTIMES,REND) 20 PRINT 999, REND-RSTART (gdb) b 11 Breakpoint 1 at 0x804811d: file woodzh.for, line 11. (gdb) run Starting program: /tmp/MC7B/bear/default/woodzh/woodzh warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x00c53d90 in write () from /usr/lib/libc.so.1 (gdb) i r eax 0xcbb6a0 13350560 ecx 0x0 0 edx 0x0 0 ebx 0xcd9ff4 13475828 esp 0xbffff480 0xbffff480 ebp 0xbffff49c 0xbffff49c esi 0x0 0 edi 0x0 0 eip 0xc53d90 0xc53d90 <write> eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x00c53d90 in write () from /usr/lib/libc.so.1 #1 0x00babca0 in ?? () from /usr/lib/libc.so.1 (gdb) q Next, to eliminate the possibility that the gfortran program itself was the cause of the error, I pared it down to a trivial program with no references to external library programs: bear@nomad:/tmp/MC7B/bear/default/woodzh$ bear@nomad:/tmp/MC7B/bear/default/woodzh$ gdb woodzh GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/MC7B/bear/default/woodzh/woodzh...done. (gdb) l 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 (gdb) b 4 Breakpoint 1 at 0x804811d: file woodzh.for, line 4. (gdb) run Starting program: /tmp/MC7B/bear/default/woodzh/woodzh warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x007c6d90 in write () from /usr/lib/libc.so.1 (gdb) q And to make sure, I processed this executable via Valgrind: bear@nomad:/tmp/MC7B/bear/default/woodzh$ valgrind -v ./woodzh ==30229== Memcheck, a memory error detector ==30229== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==30229== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==30229== Command: ./woodzh ==30229== --30229-- Valgrind options: --30229-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --30229-- -v --30229-- Contents of /proc/version: --30229-- Linux version 2.6.31-19-generic (buildd@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010 --30229-- Arch and hwcaps: X86, x86-sse1-sse2 --30229-- Page sizes: currently 4096, max supported 4096 --30229-- Valgrind library directory: /usr/lib/valgrind --30229-- Reading syms from /lib/libc-2.10.1.so (0x4000000) --30229-- Reading debug info from /lib/libc-2.10.1.so .. --30229-- .. CRC mismatch (computed b45cc142 wanted d58c444b) --30229-- Reading debug info from /usr/lib/debug/lib/libc-2.10.1.so .. --30229-- Reading syms from /tmp/MC7B/bear/default/woodzh/woodzh (0x8048000) --30229-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000) --30229-- object doesn't have a dynamic symbol table --30229-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp --30229-- Reading suppressions file: /usr/lib/valgrind/default.supp ==30229== ==30229== Process terminating with default action of signal 11 (SIGSEGV) ==30229== General Protection Fault ==30229== at 0x40BED90: write (in /lib/libc-2.10.1.so) ==30229== by 0x4016CC6: __libc_main (version.c:73) ==30229== ==30229== HEAP SUMMARY: ==30229== in use at exit: 0 bytes in 0 blocks ==30229== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==30229== ==30229== All heap blocks were freed -- no leaks are possible ==30229== ==30229== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==30229== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault Second half (CentOS 5.5): Here is a run similar to the above, except that the calls to the DTIME routine have been commented out. In this case the program was statically loaded: [tosva@centosva32 woodzh]$ ./woodzh Segmentation fault [tosva@centosva32 woodzh]$ [tosva@centosva32 woodzh]$ [tosva@centosva32 woodzh]$ [tosva@centosva32 woodzh]$ [tosva@centosva32 woodzh]$ gdb woodzh GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/MC7B/tosva/default/woodzh/woodzh...done. (gdb) b 11 Breakpoint 1 at 0x804a352: file woodzh.for, line 11. (gdb) l 1 PROGRAM FC000000 2 IMPLICIT REAL*8 (A-H,O-Z) 3 COMMON /FC3000/MPAD,MAXB,IBUC(2,5000) 4 REAL*8 DBUC(5000) 5 CHARACTER*4 CBUC(2,5000) 6 EQUIVALENCE (IBUC(1,1),DBUC(1)) 7 EQUIVALENCE (CBUC(1,1),IBUC(1,1)) 8 REAL RTIMES(2),RSTART,REND 9 COMMON /FC3007/ JPAD,MVDT,NVDT,KVDT,VDT(2,3000) 10 COMMON/FC3001/NUN(22),NGRAFS,KDEBUG,INITA,INITB,INITC,INITD (gdb) l 11 C CALL DTIME(RTIMES,RSTART) 12 MAXB=5000 13 MVDT=3000 14 CALL FC0001(3000,"WOODZH",1) 15 CALL WOODZH 16 CALL FC0391(-1,"CLOSE LUSCTOC") 17 CALL FC0392(-1,"CLOSE LUPRTOC") 18 CALL FCLTERM 19 C CALL DTIME(RTIMES,REND) 20 C PRINT 999, REND-RSTART (gdb) run Starting program: /tmp/MC7B/tosva/default/woodzh/woodzh warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x001c3a20 in write () from /usr/lib/libc.so.1 (gdb) bt #0 0x001c3a20 in write () from /usr/lib/libc.so.1 #1 0x00116fd0 in __libc_print_version () from /usr/lib/libc.so.1 #2 0x00116ff7 in __libc_main () from /usr/lib/libc.so.1 #3 0x00000001 in ?? () Now here is the equivalent Valgrind run: [tosva@centosva32 woodzh]$ valgrind --verbose ./woodzh ==18869== Memcheck, a memory error detector ==18869== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==18869== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==18869== Command: ./woodzh ==18869== --18869-- Valgrind options: --18869-- --verbose --18869-- Contents of /proc/version: --18869-- Linux version 2.6.18-194.el5 (mockbuild@builder16.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Apr 2 14:58:35 EDT 2010 --18869-- Arch and hwcaps: X86, x86-sse1-sse2 --18869-- Page sizes: currently 4096, max supported 4096 --18869-- Valgrind library directory: /usr/lib/valgrind --18869-- Reading syms from /lib/libc-2.5.so (0x101000) --18869-- Reading syms from /tmp/MC7B/tosva/default/woodzh/woodzh (0x8048000) --18869-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux (0x38000000) --18869-- object doesn't have a dynamic symbol table --18869-- Reading suppressions file: /usr/lib/valgrind/default.supp ==18869== ==18869== Process terminating with default action of signal 11 (SIGSEGV) ==18869== General Protection Fault ==18869== at 0x1C3A20: write (in /lib/libc-2.5.so) ==18869== by 0x116FF6: __libc_main (in /lib/libc-2.5.so) ==18869== ==18869== HEAP SUMMARY: ==18869== in use at exit: 0 bytes in 0 blocks ==18869== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==18869== ==18869== All heap blocks were freed -- no leaks are possible ==18869== ==18869== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==18869== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault If I can be of further help, please contact me. -- Joseph 'Bear' Thames MetaCalculus, LLC and Meta Science Foundation (505) 977-9024 - Cell Phone beartham@gmail.com
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
If you cannot reproduce a problem with a valid C program it is no problem in the C library. Don't submit Fortran code.
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
> 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?
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. >