stdout not open?

[Randy Yates]

When I try

fprintf(file, "Report of File %s\n", sMF->fileName);

I get a core dump. This works fine if fprintf is changed to
sprintf and a string buffer used instead as the first
parameter.

It looks like the standard descriptors are not really open.

This is Sun/Solaris

SunOS usrts005 5.8 Generic_117350-08 sun4u sparc SUNW,Ultra-5_10

using gcc

Reading specs from /vobs/edgedsp_tools/solaris/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4/specs
Configured with: ../../gcc-3.0.4/configure --prefix=/vobs/edgedsp_tools/solaris
Thread model: posix
gcc version 3.0.4

 

[Martin Ambuhl]

When I try

fprintf(file, "Report of File %s\n", sMF->fileName);

I get a core dump. This works fine if fprintf is changed to
sprintf and a string buffer used instead as the first
parameter.

It looks like the standard descriptors are not really open.

'file' is not the name of a standard stream.

 

[Eric Sosman]

When I try

fprintf(file, "Report of File %s\n", sMF->fileName);

I get a core dump. This works fine if fprintf is changed to
sprintf and a string buffer used instead as the first
parameter.

It looks like the standard descriptors are not really open.

`file' is not a "standard descriptor;" you need to
fopen() it for yourself. Note that fopen() can fail, so
you must check the returned value against NULL before
handing it to fprintf().

Another possibility is that you fopen()ed `file'
successfully but later fclose()d it; if you then pass
it to fprintf() all bets are off.

A third (perhaps less likely) possibility is that
`file' was fopen()ed successfully and is still open,
but that you used setvbuf() on it and gave it a buffer
area that was never or is no longer valid, or is
smaller than you said it was.

And a fourth possibility is that `sMF->fileName' is
what's causing the trouble: are you sure it's non-NULL,
and that it actually points to the start of a zero-
terminated string? Your experiment with sprintf() would
seem to suggest so, but how exactly did you determine
that the experiment worked correctly?

 

[Randy Yates]

`file' is not a "standard descriptor;" you need to
fopen() it for yourself. Note that fopen() can fail, so
you must check the returned value against NULL before
handing it to fprintf().

I'm sorry - that snippet was misleading. It is part of
a subroutine with file as a passed parameter, and I
am setting the parameter to "stdout" in the calling
routine.

Another possibility is that you fopen()ed `file'
successfully but later fclose()d it; if you then pass
it to fprintf() all bets are off.

You mean I fclose()d "stdout"? No, I don't think I have
done that.

A third (perhaps less likely) possibility is that
`file' was fopen()ed successfully and is still open,
but that you used setvbuf() on it and gave it a buffer
area that was never or is no longer valid, or is
smaller than you said it was.

And a fourth possibility is that `sMF->fileName' is
what's causing the trouble: are you sure it's non-NULL,
and that it actually points to the start of a zero-
terminated string? Your experiment with sprintf() would
seem to suggest so, but how exactly did you determine
that the experiment worked correctly?

OK, I've changed the test. When I call SMFReport, the
first few lines of which are:

void SMFReport(FILE* file, SMF_T* sMF)
{
UINT16_T n;
float fileUs;
BOOL_T stillKicking;

printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
// fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);

printf("here 1\n");
.
.
.


I get this:

here 0
Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $


If I change the fprintf to a printf:
void SMFReport(FILE* file, SMF_T* sMF)
{
UINT16_T n;
float fileUs;
BOOL_T stillKicking;

printf("here 0\n");
printf("SMF Report of File \n");
// fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);

printf("here 1\n");
.
.
.

it runs fine.

Could this be a problem somehow with this routine being part of a library?
I built the library myself, so I don't see how - just grasping for straws.

 

[Randy Yates]

Hey Eric et al.,

Hold off any further time on this: I think I know what
the problem is.

These libraries can be built for multiple platforms (sun,
pc, etc.). I think I may have my include paths wrong so
that the sun build is picking up a non-sun include file.

Thanks for your help so far.

--Randy

 

[Eric Sosman]

OK, I've changed the test. When I call SMFReport, the
first few lines of which are:
[...]
printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
printf("here 1\n");

I get this:

here 0
Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $

If I change the fprintf to a printf:
[...]
printf("here 0\n");
printf("SMF Report of File \n");
printf("here 1\n");

it runs fine.

Let's see: calls to printf() work fine. Since printf()
writes to stdout, this shows that the stream is open and is
working correctly. Yet fprintf(stdout,...) fails. Hmmm ...

Is it possible that there's some chicanery in a header
file that has re-#defined the `stdout' identifier? That is,
when you write fprintf(stdout,...) are you getting the real
standard output stream or does `stdout' get replaced by
`new_improved_low_carb_stdout_substitute'? You can check
this by examining the preprocessor output (you're using gcc;
it has a -E flag that lets you do this).

> Could this be a problem somehow with this routine being part
> of a library? I built the library myself, so I don't see
> how - just grasping for straws.

Well, if the library expects an initialization call that
would set up `new_improved_low_carb_stdout_substitute' and
the initialization call hasn't happened, that would explain
it. Another thing to look for: Does the library attempt to
provide its own version of fprintf()? (Or of any other
Standard library function, for that matter?) Any such
substitution -- whether by providing the function or by
using #define as above -- invokes undefined behavior from
the C language Standard's viewpoint; on particular systems
(Solaris among them) it is possible to override Standard
library functions but great care is required.

 

[Martin Ambuhl]

Randy Yates wrote:

OK, I've changed the test. When I call SMFReport, the
first few lines of which are:

void SMFReport(FILE* file, SMF_T* sMF)
{
UINT16_T n;
float fileUs;
BOOL_T stillKicking;

printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
// fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);

printf("here 1\n");
.
.
.


I get this:

here 0
Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $

Please post actual code that demonstrates your problem. If the
following code works, then you have misdiagnosed the problem:
#include <stdio.h>

typedef struct
{
char *fileName;
} SMF_T;

void SMFReport(FILE * file, SMF_T * sMF)
{
printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);
fprintf(file, "SMF Report of File \n");
fprintf(file, "SMF Report of File %s\n", sMF->fileName);
printf("here 1\n");
}

int main(void)
{
SMF_T foo = { "stdout" };
SMFReport(stdout, &foo);
return 0;
}

[Output]
here 0
SMF Report of File
SMF Report of File stdout
SMF Report of File
SMF Report of File stdout
here 1

 

[Randy Yates]

OK, I've changed the test. When I call SMFReport, the

first few lines of which are:
[...]
printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
printf("here 1\n");
I get this:

here 0

Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $ If I change the
fprintf to a printf:

[...]
printf("here 0\n");
printf("SMF Report of File \n");
printf("here 1\n");
it runs fine.

Let's see: calls to printf() work fine. Since printf()
writes to stdout, this shows that the stream is open and is
working correctly. Yet fprintf(stdout,...) fails. Hmmm ...

Is it possible that there's some chicanery in a header
file that has re-#defined the `stdout' identifier?

Yes, that was essentially my idea when I wrote in an adjacent post
that I might be using the include file for another target (like the
PC - I'm on a Sun).

But alas, gcc -E thefile.c indicates it's picking up stdio from the
right place. Or at least a sun directory. The thing I've noticed
now is that my configuration (it's complicated - I'm running
under clearcase with various tool versions mapped based on the
config spec) is selecting solaris 2.7 for the library includes
and we're using solaris 2.8. Would that cause such a
problem? Is there a different set of include files for solaris
2.8?

 

[Eric Sosman]

OK, I've changed the test. When I call SMFReport, the

first few lines of which are:
[...]
printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
printf("here 1\n");
I get this:

here 0

Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $ If I change the
fprintf to a printf:

[...]
printf("here 0\n");
printf("SMF Report of File \n");
printf("here 1\n");
it runs fine.

Let's see: calls to printf() work fine. Since printf()
writes to stdout, this shows that the stream is open and is
working correctly. Yet fprintf(stdout,...) fails. Hmmm ...

Is it possible that there's some chicanery in a header
file that has re-#defined the `stdout' identifier?

Yes, that was essentially my idea when I wrote in an adjacent post
that I might be using the include file for another target (like the
PC - I'm on a Sun).

But alas, gcc -E thefile.c indicates it's picking up stdio from the
right place. Or at least a sun directory. The thing I've noticed
now is that my configuration (it's complicated - I'm running
under clearcase with various tool versions mapped based on the
config spec) is selecting solaris 2.7 for the library includes
and we're using solaris 2.8. Would that cause such a
problem? Is there a different set of include files for solaris
2.8?

Certainly. It shouldn't (famous last words) make any
difference for the Standard library functions, though,
because the Solaris 8 libraries have the exact same APIs
as their predecessors -- we don't want everyone to recompile
all their code simply to upgrade the O/S, after all!

Nonetheless, it seems an ill-advised way to go about
things. Also, you mentioned that you're using gcc, and I
seem to recall reading somewhere that gcc likes to modify
the system-provided include files to suit its own purposes;
I don't know whether this is true for the particular gcc
version you're using (and maybe what I read was just an
ill-informed rumor) -- anyhow, there's plenty of room for
glitches.

Still, it seems more probable that something else in
your complicated configuration is doing something you don't
expect, and making the C code behave in ways that aren't
apparent from its appearance. Go back to your -E output
and examine what the crucial fprintf() looks like after
it's been through the preprocessor's wringer.

Since you seem to have some kind of configuration or
release engineering problem rather than a C language issue,
I think comp.lang.c is no longer the appropriate forum for
the matter. The C you've shown is just fine (assuming
reasonable #include files, definitions for data types and
so on), so you're faced with debugging your compilation
environment. I'm afraid comp.lang.c can't be much help
with that.

Oh, and since I've been talking about Solaris it's
probably a good idea to make explicit a disclaimer that
is usually understood tacitly on Usenet: I work for Sun,
but I do not speak for Sun. If you need an "official
position" on something, better get somebody else.

Good luck!

 

[Don Porges]

OK, I've changed the test. When I call SMFReport, the
first few lines of which are:

void SMFReport(FILE* file, SMF_T* sMF)
{
UINT16_T n;
float fileUs;
BOOL_T stillKicking;

printf("here 0\n");
fprintf(stdout, "SMF Report of File \n");
// fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);

printf("here 1\n");
.
.
.


I get this:

here 0
Bus Error (core dumped)
<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $


If I change the fprintf to a printf:
void SMFReport(FILE* file, SMF_T* sMF)
{
UINT16_T n;
float fileUs;
BOOL_T stillKicking;

printf("here 0\n");
printf("SMF Report of File \n");
// fprintf(stdout, "SMF Report of File %s\n", sMF->fileName);

printf("here 1\n");
.
.
.

it runs fine.

Could this be a problem somehow with this routine being part of a library?
I built the library myself, so I don't see how - just grasping for straws.

Note that your second version doesn't use sMF->fileName any more, so if either sMF is
bad or sMF->fileName is bad, you'll crash in the first case but not the second.

 

[Don Porges]

....something he withdraws.

 

[Randy Yates]

[a lot of good points/info snipped...]
Since you seem to have some kind of configuration or
release engineering problem rather than a C language issue,
I think comp.lang.c is no longer the appropriate forum for
the matter. The C you've shown is just fine (assuming
reasonable #include files, definitions for data types and
so on), so you're faced with debugging your compilation
environment. I'm afraid comp.lang.c can't be much help
with that.

REALLY??? First, I'm not sure why you feel the need to speak for the
multitude of folks on this group. Second, I don't see how you can
make such a conclusion. It is not a certainty that this is not a
C problem, and even if it were stricly not, it is very closely
related.

[...]
Good luck!

You mean, "Because there is some possibility your problem is not not
strictly related to C, we're (better "I'm") not going to help you
anymore, so Good luck!"???

I don't see why you feel the need to make such fine distinctions, even
if they were known to be correct. It's not like I'm asking for help
rebuilding a carburator.
--
% Randy Yates % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC % you still wander the fields of your
%%% 919-577-9882 % sorrow."
%%%% <[email protected]> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

 

[CBFalconer]

[a lot of good points/info snipped...]
Since you seem to have some kind of configuration or
release engineering problem rather than a C language issue,
I think comp.lang.c is no longer the appropriate forum for
the matter. The C you've shown is just fine (assuming
reasonable #include files, definitions for data types and
so on), so you're faced with debugging your compilation
environment. I'm afraid comp.lang.c can't be much help
with that.

REALLY??? First, I'm not sure why you feel the need to speak for the
multitude of folks on this group. Second, I don't see how you can
make such a conclusion. It is not a certainty that this is not a
C problem, and even if it were stricly not, it is very closely
related.

You have presented various snippets, and never a complete
compilable standard C program that exhibits the problem. IIRC you
are doing some sort of unspeakable things with the data pointed at
by a FILE* pointer (I may be wrong here). So I suggest you start
cutting things down to a compilable minimum that exhibits the
problem.

 

[Dan Pop]

When I try

fprintf(file, "Report of File %s\n", sMF->fileName);

I get a core dump. This works fine if fprintf is changed to
sprintf and a string buffer used instead as the first
parameter.

It looks like the standard descriptors are not really open.

Whenever you have such a suspicion, try to validate it with a trivial
program, like:

#include <stdio.h>

int main()
{
fprintf(stdout, "hello world\n");
return 0;
}

Translate and execute it *exactly* the same way you're translating and
executing your application.

If you get a core dump from this program, there is something very wrong
with your compilation/execution environment. If this program works fine,
then your problem is elsewhere.

Post a *minimal*, but complete program reproducing it and we may be
able to provide additional help.

Dan

 

[Christopher Benson-Manica]

REALLY??? First, I'm not sure why you feel the need to speak for the
multitude of folks on this group.

Because he's right.

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

Second, I don't see how you can
make such a conclusion. It is not a certainty that this is not a
C problem, and even if it were stricly not, it is very closely
related.

You mean, "Because there is some possibility your problem is not not
strictly related to C, we're (better "I'm") not going to help you
anymore, so Good luck!"???

For better or for worse, comp.lang.c is compiled with the -ansi
-pedantic flags, and as the links above will indicate, only strict C
problems are discussed here.

 

[Randy Yates]

Christopher, Eric, et al.,

I apologize for my outburst. It was probably a bad idea to
post at 3am in the morning after awaking from a bad dream!

Having said that, I still, even in light of the information
you provide below, think you guys are being a little too
pedantic. As I said, this is not necessarily NOT a "C language
problem." The universe is a little too complicated to allow
such strict lines to be enforced IN ALL SITUATIONS, therefore
there ought to be some leeway for the sake of practicality in
certain situations, and it seems like this is one of them.

I'm all for the order provided in your charter. I agree it is
a good thing. But I think just a tiny little bit of "off-topic
grace" (if it is) would increase order, not decrease it.

--Randy

 

[Michael Mair]

Hi Randy,

Having said that, I still, even in light of the information
you provide below, think you guys are being a little too
pedantic. As I said, this is not necessarily NOT a "C language
problem." The universe is a little too complicated to allow
such strict lines to be enforced IN ALL SITUATIONS, therefore
there ought to be some leeway for the sake of practicality in
certain situations, and it seems like this is one of them.

I'm all for the order provided in your charter. I agree it is
a good thing. But I think just a tiny little bit of "off-topic
grace" (if it is) would increase order, not decrease it.

If you read here regularly, you will see that rather often some
"off-topic grace" is granted.
One prerequisite met by the OP usually is the minimal example.
This is due to the fact that otherwise the possible sources of
the error in most cases cannot be determined in an easy way.
Your setup seems to be rather complicated. A minimal example that
compiles and works without an error on their box would enable the
people with the necessary experience to provided off-topic hints
in a way that goes not hard on their time.

About the narrowness: I see you posting in c.t.t where nearly
everything to do with TeX, typesetting and related tools is more
or less on-topic. We have about the same traffic here when sticking
to a rather narrow topic.
Some of the regulars provide useful hints for off-topic requests or
tell an OP where to redirect his/her request to, some don't, some
get rather acerbic.
I know that this does not hold for you, but many of the OPs do not
look at the FAQ or the charter and/or have requests that are very
far from the C language.


Cheers,
Michael

 

[Randy Yates]

This


#include <stdio.h>

int main(int argc, char **argv)
{
fprintf(stdout, "Hello World\n");
return 0;
}



results in this:



<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $ tst
Bus Error (core dumped)


--RY

 

[Eric Sosman]

This


#include <stdio.h>

int main(int argc, char **argv)
{
fprintf(stdout, "Hello World\n");
return 0;
}



results in this:



<yates_dsp-54_3.60> /vobs/annadsp_sw/midi/app/smf $ tst
Bus Error (core dumped)

That's when the program is compiled in your complicated
build configuration, right? What happens if you just fire
up gcc by hand, omitting all the jiggery-pokery? I imagine
you'll get either

- It runs fine, suggesting that there's something awry
in your build environment, or

- It also crashes, suggesting that there's something
wrong with your gcc installation.

The only error I can spot in the C code is that you're
missing a comma after "Hello" ;-)

 

[Christopher Benson-Manica]

The only error I can spot in the C code is that you're
missing a comma after "Hello" ;-)

Well, an exclamation point might help as well; enthusiasm never hurts.