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]

ma************@yahoo.com.hk (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

[dandelion]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41***************@news.individual.net...

ma************@yahoo.com.hk (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.

[Richard Bos]

"dandelion" <da*******@meadow.net> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41***************@news.individual.net...

ma************@yahoo.com.hk (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

[dandelion]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41***************@news.individual.net...

"dandelion" <da*******@meadow.net> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41***************@news.individual.net...

ma************@yahoo.com.hk (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.

[Mark McIntyre]

On 8 Dec 2004 22:56:23 -0800, in comp.lang.c , ma************@yahoo.com.hk
(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 =----

[kevin.bagust]

In article <t2********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

On 8 Dec 2004 22:56:23 -0800, in comp.lang.c , ma************@yahoo.com.hk
(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.

[Chris Torek]

In article <21**************************@posting.google.com >
Martin <ma************@yahoo.com.hk> 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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.