Segmentation faults in fprintf() ?

Segmentation faults in fprintf() ?

Post by Robert Brought » Sun, 26 Sep 1999 04:00:00



I have v2.2.10 of the kernel, libc 2.1, and v3.3.5 of XFree86.
A couple of programs I've compiled myself (knews is one of
them) get segmentation faults, at the backtrace from gdb looks
like this:
-----

 Program received signal SIGSEGV, Segmentation fault.
 0x80b18f8 in ?? ()
 (gdb) bt
 #0  0x80b18f8 in ?? ()
 #1  0x401b4896 in _IO_vfprintf ()
 #2  0x401bc961 in fprintf ()
 #3  0x400ea15d in XOpenDisplay ()
 #4  0x40060b89 in XtOpenDisplay ()
 #5  0x8058d78 in main (argc=1, argv=0xbffffd24) at main.c:510
 #6  0x40186b0f in __libc_start_main ()                                          
-----

Any ideas?

--
Spammer toll-free numbers: (800) 352-3288 ext. 2637, (877) 299-5465,
(888) 894-7694

Bob Broughton

WWW: http://infomatch.com/~rbrought
Vancouver, BC, Canada

 
 
 

Segmentation faults in fprintf() ?

Post by Jon Trulso » Fri, 08 Oct 1999 04:00:00



> I have v2.2.10 of the kernel, libc 2.1, and v3.3.5 of XFree86.
> A couple of programs I've compiled myself (knews is one of
> them) get segmentation faults, at the backtrace from gdb looks
> like this:
> -----
>  Program received signal SIGSEGV, Segmentation fault.
>  0x80b18f8 in ?? ()
>  (gdb) bt
>  #0  0x80b18f8 in ?? ()
>  #1  0x401b4896 in _IO_vfprintf ()
>  #2  0x401bc961 in fprintf ()
>  #3  0x400ea15d in XOpenDisplay ()
>  #4  0x40060b89 in XtOpenDisplay ()
>  #5  0x8058d78 in main (argc=1, argv=0xbffffd24) at main.c:510
>  #6  0x40186b0f in __libc_start_main ()                                          
> -----

        Yes... Is it possible that you are compiling a program on a RH60 system,
using libraries built on a RH5.x (or just about any non RH60) system?  Something
changed in crt1.o - replacing it with the RH5.2 version solved this problem for
some of our customers... It's ugly, but the alternative is to make sure that the
libraries (non-RH6.0 libX11?) are recompiled on RH6.0.

--

Xi Graphics,   http://www.xig.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962

#include <stddisclaimer.h>
You talk like a Ferengi.

 
 
 

Segmentation faults in fprintf() ?

Post by jtholme » Fri, 08 Oct 1999 04:00:00




> > I have v2.2.10 of the kernel, libc 2.1, and v3.3.5 of XFree86.
> > A couple of programs I've compiled myself (knews is one of
> > them) get segmentation faults, at the backtrace from gdb looks
> > like this:
> > -----

> >  Program received signal SIGSEGV, Segmentation fault.
> >  0x80b18f8 in ?? ()
> >  (gdb) bt
> >  #0  0x80b18f8 in ?? ()
> >  #1  0x401b4896 in _IO_vfprintf ()
> >  #2  0x401bc961 in fprintf ()
> >  #3  0x400ea15d in XOpenDisplay ()
> >  #4  0x40060b89 in XtOpenDisplay ()
> >  #5  0x8058d78 in main (argc=1, argv=0xbffffd24) at main.c:510
> >  #6  0x40186b0f in __libc_start_main ()
> > -----

>         Yes... Is it possible that you are compiling a program on a RH60 system,
> using libraries built on a RH5.x (or just about any non RH60) system?  Something
> changed in crt1.o - replacing it with the RH5.2 version solved this problem for
> some of our customers... It's ugly, but the alternative is to make sure that the
> libraries (non-RH6.0 libX11?) are recompiled on RH6.0.

> --

> Xi Graphics,   http://www.xig.com
> ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962

> #include <stddisclaimer.h>
> You talk like a Ferengi.

Being a programmer and seeing Many such messages, I can almost assure
you that whatever is calling Printf  is sending it one of the following:

unterminated  string  argument
pointer pointing to  address 0
bad address that causes Vprintf  or whatever it is calling to overwrite some
    part of the  executable  text area in the user space and thus the core dump.

would bet my life on one of the three

Next how to fix:

What exactly did you write , what does it do, how does it do it.
If it has any  strcpy  or such  destructive  copy  functions make
absolutely sure that the  pointers are correct and that the area
you are copying to is large enough to hold the  data being copied there,
also make sure strings are terminated correctly.vw

Make sure any calls that pass Pointers have the correct values in
them  (test this using  gdb and dump the arguments being passed
to make sure they contain what you expect them to pass)

Literally 85% or more of the Core dumps I see are  destructive
copying gone awry due to space or pointer problems.

Don't know how you program but if you are using any  Global  Variables
get rid of them, put them in the scope of your  function(s),
and pass them as  arguments to your routines  (in C)
In C++  put your data into a class to protect it.

--
jtholmes

 
 
 

Segmentation faults in fprintf() ?

Post by Robert Koma » Sat, 09 Oct 1999 04:00:00



:>
:> >  Program received signal SIGSEGV, Segmentation fault.
:> >  0x80b18f8 in ?? ()
:> >  (gdb) bt
:> >  #0  0x80b18f8 in ?? ()
:> >  #1  0x401b4896 in _IO_vfprintf ()
:> >  #2  0x401bc961 in fprintf ()
:> >  #3  0x400ea15d in XOpenDisplay ()
:> >  #4  0x40060b89 in XtOpenDisplay ()
:> >  #5  0x8058d78 in main (argc=1, argv=0xbffffd24) at main.c:510
:> >  #6  0x40186b0f in __libc_start_main ()
:> > -----

: Being a programmer and seeing Many such messages, I can almost assure
: you that whatever is calling Printf  is sending it one of the following:

: unterminated  string  argument
: pointer pointing to  address 0
: bad address that causes Vprintf  or whatever it is calling to overwrite some
:     part of the  executable  text area in the user space and thus the core dump.

: would bet my life on one of the three

Hmmm.  I have some Fortran code that does heavy I/O and I get similar error
messages (at random times) when running my machine at its specified clock
rate (266 MHz; it's getting on in age).  When I underclock the machine,
the fprintf errors go away.  So, in my case, the same fprintf error
messages seem to be due to hardware-generated corruption, and not bad
programming.  Maybe the original poster has similar problems.

Cheers,
Rob Komar

P.S.  My newsreader won't let me reply with less of my text than quoted text,
so I'm going to have to pad it out with garbage.  Sorry.

blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah

 
 
 

Segmentation faults in fprintf() ?

Post by Jon Trulso » Sat, 09 Oct 1999 04:00:00





>> > I have v2.2.10 of the kernel, libc 2.1, and v3.3.5 of XFree86.
[...]
> Being a programmer and seeing Many such messages, I can almost assure
> you that whatever is calling Printf  is sending it one of the following:
> unterminated  string  argument
> pointer pointing to  address 0
> bad address that causes Vprintf  or whatever it is calling to overwrite some
>     part of the  executable  text area in the user space and thus the core dump.

        No.  ;-) I am also a developer, and I have seen this exact stack trace
many times since RH6.0 came out and some of our customers started sending us
these.  All I have to do to reproduce it is:

        Load up our X11 libs on a rh6.0 system (they were built on a RH5.2
system).  Compile something like xterm on the RH6.0 box.  fire it up - it will
work fine.  Now, remove access to the display (xhost -), give it a bogus font,
anything that causes _XError to run and try it again.  As soon as it wants to
issue and output it'll core.  I whipped up a simple application that opens a
window and simply draws a line.  Just using printf("Hi there") was enough to kill
it, before any X calls were even made. Replacing crt1.o with the RH5.2 version (or
recompiling the libs under rh6.0), 'fixes' it.

        We had enough people with this problem, we made it into a FAQ on our
website.

        The issue (if what he described above is true) seems to be combining the
RH5.2 libs with the rh6.0 crt1.o during link.  Stuff compiled on 5.2 works fine on
6.0...  I suspect something in varargs handling changed between glibc 2.0 and
2.1... Haven't actually looked, so I do't know.

Quote:> would bet my life on one of the three

        I hope not... ;-)

[...]

--

Xi Graphics,   http://www.xig.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962

#include <stddisclaimer.h>
You talk like a Ferengi.

 
 
 

1. Compiling *** VIM 5.3 *** Segmentation Fault..what is Seg-Fault..MEM Bounds?

Compiled fine........upgraded from 4.6  REdhat 5.0

got the src and rt of the autors VIM site via ftp.vim.org

changed the first requested by auther line in ".vimrc" file to not
read "version 4.00" and it worked once.....Gee

Now I am using it on everything ...DOS Win95 even NT40 !!!!

I know go back to the early version but still.....
what or why ...

"Segmentation Fault...Core dump"
thanks in advance.....Matt

2. EMU Compliance

3. Page Faults/Segmentation Faults??

4. Bulk Mail Software

5. "Segmentation fault( core dumped ) "<--- sentence is driving me mad!!!!!

6. Pioneer DR-U124X SCSI CD-ROM

7. segmentation fault ?

8. ufsdump verify option and DAT

9. Get "Segmentation fault (core dumped)" but no core file found

10. Segmentation Faults and Bus Errors

11. Dosemu0.52 : Segmentation fault?

12. Segmentation fault

13. Segmentation fault on RH Linux 5.1