Re: Interpreting program core dump in mdb
- From: "Mr. Uh Clem" <uhclem@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 28 Mar 2008 10:11:38 -0400
EricF wrote:
So anyway, some pointers to interpreting the context around a crashIt would help if you built with debug enabled, which is a -g parameter.
using mdb would be appreciated.
TIA
Eric
We did build a -g version here and purposely bombed it by feeding NULL
as the strncpy source argument. For some reason, the ::stack display
was no more symbolic, remaining cryptic without a secret decoder ring.
We put the customer through a lot trying various things prior to
obtaining the core dump. So we are kind of laying off them for
a little bit. We'd like to understand what we are seeing before
bothering them again with another binary. (And honestly, the nature
of this thing makes me suspect that -g will make the problem go
away. Sticking debug statements near the strncpy seemed to heal
things...)
Nobody can tell what the values being displayed by ::stack are?
--
Clem
"If you push something hard enough, it will fall over."
- Fudd's first law of opposition
.
- Follow-Ups:
- Re: Interpreting program core dump in mdb
- From: Mark Holland
- Re: Interpreting program core dump in mdb
- References:
- Interpreting program core dump in mdb
- From: Mr. Uh Clem
- Re: Interpreting program core dump in mdb
- From: EricF
- Interpreting program core dump in mdb
- Prev by Date: Re: Can fork be used in a signal handler?
- Next by Date: Re: Can fork be used in a signal handler?
- Previous by thread: Re: Interpreting program core dump in mdb
- Next by thread: Re: Interpreting program core dump in mdb
- Index(es):