> > 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.