public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/11865] New: SegFault in libc_print_version on program start
@ 2010-07-31 17:27 beartham at gmail dot com
2010-07-31 17:38 ` [Bug libc/11865] " beartham at gmail dot com
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: beartham at gmail dot com @ 2010-07-31 17:27 UTC (permalink / raw)
To: glibc-bugs
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
--
Summary: SegFault in libc_print_version on program start
Product: glibc
Version: 2.10
Status: NEW
Severity: critical
Priority: P1
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: beartham at gmail dot com
CC: glibc-bugs at sources dot redhat dot com
GCC build triplet: same
GCC host triplet: x86-Intel-CentOS-5.5|Kubuntu8.04|Kubuntu9.10
GCC target triplet: same
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/11865] SegFault in libc_print_version on program start
2010-07-31 17:27 [Bug libc/11865] New: SegFault in libc_print_version on program start beartham at gmail dot com
@ 2010-07-31 17:38 ` 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
2 siblings, 0 replies; 5+ messages in thread
From: beartham at gmail dot com @ 2010-07-31 17:38 UTC (permalink / raw)
To: glibc-bugs
------- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/11865] SegFault in libc_print_version on program start
2010-07-31 17:27 [Bug libc/11865] New: SegFault in libc_print_version on program start 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
2 siblings, 0 replies; 5+ messages in thread
From: drepper at redhat dot com @ 2010-07-31 18:17 UTC (permalink / raw)
To: glibc-bugs
------- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/11865] SegFault in libc_print_version on program start
2010-07-31 17:27 [Bug libc/11865] New: SegFault in libc_print_version on program start 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
2 siblings, 0 replies; 5+ messages in thread
From: drepper at redhat dot com @ 2010-07-31 21:22 UTC (permalink / raw)
To: glibc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <bug-11865-131@http.sourceware.org/bugzilla/>]
* [Bug libc/11865] SegFault in libc_print_version on program start
[not found] <bug-11865-131@http.sourceware.org/bugzilla/>
@ 2014-06-30 17:27 ` fweimer at redhat dot com
0 siblings, 0 replies; 5+ messages in thread
From: fweimer at redhat dot com @ 2014-06-30 17:27 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-06-30 17:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-31 17:27 [Bug libc/11865] New: SegFault in libc_print_version on program start 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
[not found] <bug-11865-131@http.sourceware.org/bugzilla/>
2014-06-30 17:27 ` fweimer at redhat dot com
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).