What can cause a fopen call to lock up?

[Mister Zimbu]

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.

#include "tracer.h"
#include <stdio.h>
#include <stdlib.h>
#include <memory.h>

#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...)

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( "\0\0\0\0\0\0", 1, 6, f );
fclose( f );
}

 

[Victor Bazarov]

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

 

[Mister Zimbu]

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.

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