Sign in to follow this  
Raeldor

fopen does not work in release build, but works in debug build

Recommended Posts

My line is...
	// load texture from file
	if ((myFile=fopen(in_filename, "rb")) == NULL)
		return FALSE;

which works perfectly in debug build, but not in release build. Anyone have any clues as to why? The filename seems valid in both. Thanks

Share this post


Link to post
Share on other sites
Try directly placing in a string of text first in place of in_filename and see if it works. If it does, then chances are you are having some problem with the string not being NULL terminated in release mode.

What I mean is if you have something like: char in_filename[256]; sprintf(in_filename,"MyFile.bmp") in Debug mode, it is Null terminated, but in release mode it is not.

To remedy that in relase mode, make sure you have something along the lines of:
char in_filename[256] = {0}; or memset( in_filename, 0, 256 );

You may finally want to check to see if the error is with the fopen function as well. Take a look at this ferror example to do so. Good luck!

Share this post


Link to post
Share on other sites
Even when I put...

if ((myFile=fopen("c:\\oakqrtrt.tga", "rb")) == NULL)

It still doesn't open in relesae, but works fine in debug!

Share this post


Link to post
Share on other sites
Quote:
Original post by Drew_Benton
I think the problem then lies somewhere else then. Are you sure that code fails at that specific spot in release mode? Other than that, I'm out of ideas with that code right there.


Yeah, I am stepping through in VS2003. Definitely seems to be on that line.

Share this post


Link to post
Share on other sites
Hmm, that's interesting. I changed to...


// load texture from file
myFile=fopen("c:\\oakqrtrt.tga", "rb");
if (myFile == NULL)
{
// if ((myFile=fopen("c:\\oakqrtrt.tga", "rb")) == NULL)
// if ((myFile=fopen(in_filename, "rb")) == NULL)
printf("test");
return FALSE;
}



And when I step thru in release it does the fopen, but on the line where it's doing the if (myFile == NULL), it goes straight to the end of the function without doing the printf part.

Share this post


Link to post
Share on other sites
ummm, I know this sounds stupid, but is the file you're trying to open present in the location where the release build would be placed? maybe it's trying to open a file that's not there?

Share this post


Link to post
Share on other sites
Ugh, my bad. It's not that line it's failing on. After going to the end of the function it jumps back to the section of code underneath... wierd... must be a strange visual studio thing.

Looks like the malloc is failing... is there any reason a simple malloc would fail during runtime? It's only a small allocation (256k). Is there a limit?

Share this post


Link to post
Share on other sites
Quote:
Original post by Raeldor
Ugh, my bad. It's not that line it's failing on. After going to the end of the function it jumps back to the section of code underneath... wierd... must be a strange visual studio thing.

Looks like the malloc is failing... is there any reason a simple malloc would fail during runtime? It's only a small allocation (256k). Is there a limit?


Ok, forget it. Trying to debug in VS2003 in runtime mode is just giving me wierd results. It gives me variable values for some variables but not other and the ones it does give are wrong. I'll find another way.

Thanks all

Share this post


Link to post
Share on other sites
Sometimes it happens to me.. but VS does not do a proper compile with the available debug information. So things that aren't even on that line during step-through happen.

Usually, especially when I'm switching from debug to release and vice versa, I do a clean-rebuild.
I also do a clean-rebuild every so often, and when I'm encountering strange errors.

[Edited by - sordid on August 31, 2005 11:19:30 PM]

Share this post


Link to post
Share on other sites
Ok, this is really pissing me off now. It's failing on...


if (fread(m_imageData, sizeof(unsigned long), header.width*header.height, myFile) != header.width*header.height)
return FALSE;



If I turn optimizations off it works. If I turn them on it fails.

Share this post


Link to post
Share on other sites
Release build means that Debug information is removed. You can experiment with the different levels of debug types. But this is the point of having a release build is that the code gets smaller and faster with a release build.

I have run into release issues in the past, and to fight this I have a target platform that is called "Near-Release" which has some basic debugging information in it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Skoobydoo
Release build means that Debug information is removed. You can experiment with the different levels of debug types. But this is the point of having a release build is that the code gets smaller and faster with a release build.

I have run into release issues in the past, and to fight this I have a target platform that is called "Near-Release" which has some basic debugging information in it.


Yes, I know that it means it's removed, but VS isn't completely bug-free. I shouldn't have said "or vice versa", as I meant "and vice versa". (changed to reflect that).

Can you explain for the people what sort of settings you have in this Near-Release Build for those interested?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this