 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Mister Zimbu
Guest
|
 Posted: Wed Oct 27, 2004 12:40 pm Post subject: What can cause a fopen call to lock up? |
 |
|
I'm having problems with a program I wrote- when it comes time to output
a file, the call to fopen locks up and I have to break the program
manually. I've pinpointed the actual stopping point to fopen, but due
to my lack of knowledge with gdb, etc., I don't know how to go any
further with the debugging from there.
I'm running gcc under cygwin. Sorry for the lack of information.
Here's the code in question, please no comments on style, as that is not
relevant or wanted at this time.
Other snippets-
the first (working) program was compiled alone:
gcc tracer.C
this one links with the first (what I'm doing here is seperating code
from the main functions in tracer.C so I can build some extensions off
of it easier if I need to):
gcc tracer.C raytracer_tga.C
u1, u2, and u4 are typedef'ed in tracer.h and are 1 byte, 2 byte, and 4
byte variable types, respectively.
Help me out please 
Thanks.
| Quote: | #include "tracer.h"
#include
#include
#include
#pragma pack (1)
typedef struct {
u2 bfType;
u4 bfSize;
u2 bfReserved1;
u2 bfReserved2;
u4 bfOffBits;
} bitmapFileHeader;
typedef struct {
u4 biSize;
u4 biWidth;
u4 biHeight;
u2 biPlanes;
u2 biBitCount;
u4 biCompression;
u4 biSizeImage;
u4 biXPelsPerMeter;
u4 biYPelsPerMeter;
u4 biClrUsed;
u4 biClrImportant;
} bitmapInfoHeader;
typedef struct {
u1 idlength;
u1 colorMapType;
u1 dataTypeCode;
u2 colorMapOrigin;
u2 colorMapLength;
u1 colorMapDepth;
u2 x_origin;
u2 y_origin;
u2 width;
u2 height;
u1 bitsPerPixel;
u1 imageDescriptor;
} TgaHeader;
#pragma pack ()
|
(other functions...)
| Quote: | void writeToFile( char *filename, vec *pixels, u2 xSize, u2 ySize ) {
int i;
int y;
TgaHeader hdr;
int numPixels = xSize*ySize;
hdr.idlength = 0;
hdr.colorMapType = 0;
hdr.dataTypeCode = 2;
hdr.colorMapOrigin = 0;
hdr.colorMapLength = 0;
hdr.colorMapDepth = 0;
hdr.x_origin = 0;
hdr.y_origin = 0;
hdr.width = xSize;
hdr.height = ySize;
hdr.bitsPerPixel = 24;
hdr.imageDescriptor = 0x20;
FILE *f;
f = fopen( "out.tga", "wb" );
fwrite( &hdr, 1, sizeof( hdr ), f );
for( y = 0; y < numPixels; y++ ) {
char toWr[3];
toWr[0] = (char)(255.0*pixels[ y ].z );
toWr[1] = (char)(255.0*pixels[ y ].y ); toWr[2] =
(char)(255.0*pixels[ y ].x );
fwrite( &toWr, 1, 3, f );
}
fwrite( " ", 1, 6, f );
fclose( f );
}
|
|
|
| Back to top |
|
 |
Victor Bazarov
Guest
|
| Posted: Wed Oct 27, 2004 2:15 pm Post subject: Re: What can cause a fopen call to lock up? |
|
|
Mister Zimbu wrote:
| Quote: | I'm having problems with a program I wrote- when it comes time to output
a file, the call to fopen locks up and I have to break the program
manually. I've pinpointed the actual stopping point to fopen, but due
to my lack of knowledge with gdb, etc., I don't know how to go any
further with the debugging from there.
I'm running gcc under cygwin. Sorry for the lack of information.
[...]
|
Well, 'fopen' doesn't return until it either opens the stream or fails
to do so. In the former case it returns the pointer to the stream, in
the latter it returns NULL. Apparently, your implementation, when run
on your system, is doing something wrong so that 'fopen' cannot even
recognise a failure to open a file. There can be two obvious reasons
for that. (A) 'fopen' forwards the request to open the stream to some
other subsystem that itself locks up (like network file system, for
example) and you're just not patient enough to wait for it to time out,
or (b) something has screwed up the execution environment of your program
so badly that the standard library cannot work without locking up. Both
of those reasons have nothing to do with the code you posted. What is
worse, both of those situations are really difficult to diagnose and
correct.
Try asking in a gcc newsgroup or a Windows newsgroup, perhaps folks there
have experienced something like that (with cygwin) and might have more
suggestions.
Victor
|
|
| Back to top |
|
|
Mister Zimbu
Guest
|
| Posted: Wed Oct 27, 2004 4:02 pm Post subject: Re: What can cause a fopen call to lock up? |
|
|
Victor Bazarov wrote:
Thanks for the help; this sounds like it'll be fun .
One oddity is this code is more or less copy-pasted from another program
written (I'm moving some functions around in that program so I can
easily extend this- ie, make builds that will render to a GL window or
another file format). The original version's backup still compiles and
runs fine.
Oh well, I'll post there in a bit. Thanks.
| Quote: | Mister Zimbu wrote:
I'm having problems with a program I wrote- when it comes time to
output a file, the call to fopen locks up and I have to break the
program manually. I've pinpointed the actual stopping point to fopen,
but due to my lack of knowledge with gdb, etc., I don't know how to go
any further with the debugging from there.
I'm running gcc under cygwin. Sorry for the lack of information.
[...]
Well, 'fopen' doesn't return until it either opens the stream or fails
to do so. In the former case it returns the pointer to the stream, in
the latter it returns NULL. Apparently, your implementation, when run
on your system, is doing something wrong so that 'fopen' cannot even
recognise a failure to open a file. There can be two obvious reasons
for that. (A) 'fopen' forwards the request to open the stream to some
other subsystem that itself locks up (like network file system, for
example) and you're just not patient enough to wait for it to time out,
or (b) something has screwed up the execution environment of your program
so badly that the standard library cannot work without locking up. Both
of those reasons have nothing to do with the code you posted. What is
worse, both of those situations are really difficult to diagnose and
correct.
Try asking in a gcc newsgroup or a Windows newsgroup, perhaps folks there
have experienced something like that (with cygwin) and might have more
suggestions.
Victor
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
