«

My program cored and the following is the call stack in dbx. I would
like to know what are the possibilities that when perror is being
called, it will core?

dbx: warning: cannot get thread count -- generic libthread_db.so error
dbx: warning: thread related commands will not be available
dbx: warning: see `help lwp', `help lwps' and `help where'
(l@22) dbx: warning: cannot get thread count -- generic
libthread_db.so error
terminated by signal SEGV (no mapping at the fault address)
0xff111278: ferror+0x0028: ldub [%i0 + 0xe], %o0
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
=>[1] ferror(0x0, 0x53683c, 0x53683c, 0xff13fdc8, 0xff1ea08c, 0x39),
at 0xff111278
[2] GL_MsgLogger::record(0xfbca30, 0x0, 0xfc8f1f98, 0x312, 0x1,
0xfc8f175d), at 0x380198
[3] GL_V5Session::Send(0xfc3a30, 0xfc8f85a0, 0x531628, 0xfbca30,
0xfc8f6008, 0xfc8f6010), at 0x34b0dc

(Martin) wrote:

> My program cored and the following is the call stack in dbx. I would
> like to know what are the possibilities that when perror is being
> called, it will core?

There's no reason for perror() itself to dump core, so the only thing I
can imagine is that you made a mistake earlier on, either clobbering
over the allocation arena, or assigning a bogus value to errno; and that
this earlier error went unnoticed until it confused perror().

Richard

"Richard Bos" <> wrote in message
news:...
> (Martin) wrote:
>
> > My program cored and the following is the call stack in dbx. I would
> > like to know what are the possibilities that when perror is being
> > called, it will core?
>
> There's no reason for perror() itself to dump core, so the only thing I
> can imagine is that you made a mistake earlier on, either clobbering
> over the allocation arena, or assigning a bogus value to errno; and that
> this earlier error went unnoticed until it confused perror().

Passing perror an invalid pointer would do the trick. Not bthat perror is to
blame for that, but *effectively* it's perror which causes the coredump by
dereferencing the faulty pointer. I agree, however, that the fault is not
perror().

So i'd advice to check wether the pointer which is passed to perror is
either valid or null.

"dandelion" <> wrote:

>
> "Richard Bos" <> wrote in message
> news:...
> > (Martin) wrote:
> >
> > > My program cored and the following is the call stack in dbx. I would
> > > like to know what are the possibilities that when perror is being
> > > called, it will core?
> >
> > There's no reason for perror() itself to dump core, so the only thing I
> > can imagine is that you made a mistake earlier on, either clobbering
> > over the allocation arena, or assigning a bogus value to errno; and that
> > this earlier error went unnoticed until it confused perror().
>
> Passing perror an invalid pointer would do the trick. Not bthat perror is to
> blame for that, but *effectively* it's perror which causes the coredump by
> dereferencing the faulty pointer. I agree, however, that the fault is not
> perror().

Erm... yes, of course. I was focusing on the error message, and
completely failed to look at the actual argument. Stupid.

Richard

"Richard Bos" <> wrote in message
news:...
> "dandelion" <> wrote:
>
> >
> > "Richard Bos" <> wrote in message
> > news:...
> > > (Martin) wrote:
> > >
> > > > My program cored and the following is the call stack in dbx. I would
> > > > like to know what are the possibilities that when perror is being
> > > > called, it will core?
> > >
> > > There's no reason for perror() itself to dump core, so the only thing
I
> > > can imagine is that you made a mistake earlier on, either clobbering
> > > over the allocation arena, or assigning a bogus value to errno; and
that
> > > this earlier error went unnoticed until it confused perror().
> >
> > Passing perror an invalid pointer would do the trick. Not bthat perror
is to
> > blame for that, but *effectively* it's perror which causes the coredump
by
> > dereferencing the faulty pointer. I agree, however, that the fault is
not
> > perror().
>
> Erm... yes, of course. I was focusing on the error message, and
> completely failed to look at the actual argument. Stupid.

Considering all the times i've put my foot in my mouth, i would hardly call
it that.

Errare humanum est, after all.

On 8 Dec 2004 22:56:23 -0800, in comp.lang.c ,
(Martin) wrote:

>My program cored and the following is the call stack in dbx. I would
>like to know what are the possibilities that when perror is being
>called, it will core?

calling perror() with a null argument would seem to be UB, so that might
core.

You might also get a core if your stack were so horribly corrupted before
the perror call, that it was working with garbage. Suspect earlier
problems.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

In article <>,
Mark McIntyre <> wrote:
> On 8 Dec 2004 22:56:23 -0800, in comp.lang.c ,
> (Martin) wrote:

> >My program cored and the following is the call stack in dbx. I would
> >like to know what are the possibilities that when perror is being
> >called, it will core?

> calling perror() with a null argument would seem to be UB, so that might
> core.

No, calling perror() with a null argument is defined. From the standard
(7.19.10.4#2):

....first (if s is not a null pointer and the character pointed to by S is
not the null character), the string pointed to by s followed by a colon (
: ) ....

which suggests that s can be the null pointer.

Kevin Bagust.

In article < >
Martin <> wrote:
>My program cored and the following is the call stack in dbx. I would
>like to know what are the possibilities that when perror is being
>called, it will core?

Calling perror() with an invalid argument could do that. What I
do not understand is why you are asking about perror() when the
text below suggests the code is calling ferror():

>terminated by signal SEGV (no mapping at the fault address)
>0xff111278: ferror+0x0028: ldub [%i0 + 0xe], %o0
>(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
>=>[1] ferror(0x0, 0x53683c, 0x53683c, 0xff13fdc8, 0xff1ea08c, 0x39),
>at 0xff111278
> [2] GL_MsgLogger::record(0xfbca30, 0x0, 0xfc8f1f98, 0x312, 0x1,
>0xfc8f175d), at 0x380198
> [3] GL_V5Session::Send(0xfc3a30, 0xfc8f85a0, 0x531628, 0xfbca30,
>0xfc8f6008, 0xfc8f6010), at 0x34b0dc

It is hard to be sure (because "optimization" can change things), but
given what I know about the specific machine, and this output from
the debugger, it looks like someone did:

ferror(fp)

where fp == NULL.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.