[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1219548364.15228.4.camel@zem>
Date: Sat, 23 Aug 2008 23:26:04 -0400
From: Calvin Walton <calvin.walton@...il.com>
To: 7eggert@....de
Cc: Wang Yi <leonidwang@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Segmentation fault details?
On Sat, 2008-08-23 at 22:23 +0200, Bodo Eggert wrote:
> Wang Yi <leonidwang@...il.com> wrote:
>
> > I'd like to know some details about segmentation fault.
> > What I mean is when a program accesses invalid memory area, it will
> > get a SIGSEGV signal from kernel, and a message "Segmentation fault".
> >
> > I also find that dmesg can show we something like this:
> > ProgramName[Pid]: segfault at xxxx eip xxxx esp xxxx error x
> > It is useful and provides the first-step information for further
> > debug/analysis.
> >
> > My question is how dmesg gets the information, and if there are any
> > "decent" way to get this and maybe more information(An "indecent" way
> > I came to is grep dmesg)
> > so that I can perform some basic auto analysis.
>
> I'm wondering if the default handler might print this information isntead
> of the plain segmentation violation.
If you want to debug a segfaulting user-space program, there's a
somewhat better way to get this information (and a whole lot more info,
too...), and it's been around in various unixes for ages: core dumps
(core files).
Unfortunately (but given the state of modern linux desktop programs,
understandably), most current linux distributions ship with core dumps
turned off. But it isn't too hard to turn them back on if you have a
segfaulting program that you want to debug.
--
Calvin Walton <calvin.walton@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists