in what circustances perror would cause core dump?

[Martin]

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

 

[Richard Bos]

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

 

[dandelion]

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.

 

[Richard Bos]

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

 

[dandelion]

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.

 

[Mark McIntyre]

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.

 

[kevin.bagust]

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

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.

 

[Chris Torek]

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.