Fwd: Re: [vox-tech] debian woody to sarge upgrade = dead xserver: solved
Richard Harke
rharke at earthlink.net
Thu Aug 26 21:30:40 PDT 2004
On Thursday 26 August 2004 19:08, Jonathan Stickel wrote:
> Ken Bloom wrote:
> > On Thu, 26 Aug 2004 15:12:51 -0700
> >
> > Rick Moen <rick at linuxmafia.com> wrote:
> >>Quoting Ken Bloom (kabloom at ucdavis.edu):
> >>>I don't think that's correct. Signal 11 is better known as SIGSEGV,
> >>>and it is a segmentation fault usually caused by a programmer
> >>>dereferencing an uninitialized pointer (or a deleted pointer). It's
> >>>entirely a programmer error.
> >>
> >>Well, congratulations on encountering so little bad RAM. ;-> Our
> >>experience differs.
> >>
> >>Quoting (selectively) a small piece of the SIG 11 FAQ:
> >>
> >> QUESTION
> >>
> >> Ok. I may have a hardware problem what is it?
> >>
> >> ANSWER
> >>
> >> If it happens to be the hardware it can be:
> >>
> >> * Main memory.
> >> [...]
> >
> > My main experience with segfaults, when I've cared enough to figure out
> > what was going on, has been when I've been writing C++ programs that
> > used new and delete. If you're going to debug a segfault, you need to
> > debug for a software problem first, and you need to debug for it
> > exhaustively to make sure it's not a software problem - that includes
> > sending strace/ltrace/valgrind/whatever output to the developer
> > and asking them what they think. *Then* you can conclude it's a hardware
> > problem.
>
> Well, if its new or suspect hardware, you can boot up memtest86(+).
I recently did have some bad memory and I did get segfaults. But I also got
illegal instructions and even unknown error. A couple of times the system
simply stopped working and required a hardware reset. The fact that the
problem was not consistently related to what software was running, indicated
a hardware problem. Running memtest86+ confimed it.
Richard
More information about the vox-tech
mailing list