Member Avatar for drock9975

I've never seen this before and am perplexed beyond belief... by the way I'm using Visual Studio

I have a rather large program/game i'm working on right now, and it reads in via ifstream file i/o from binary files in several locations to initialize variables. For some reason for one set of files to read in it is opening and reading the wrong files, but only in release mode. Debug mode works like a charm, but in release it just won't work right. I'm getting strings longer than 4 bytes thrown into my ints and bunk values into others.

bool	CParticleEffect::LoadEffect(char* fileName)
{
	ifstream file;
	file.open(fileName,ios_base::in | ios_base::binary);

	if(!file.is_open())
	{
		ofstream problem;
		problem.open("particle_problem.txt", ios_base::out | ios_base::trunc);
		problem.write(fileName, sizeof(fileName));
		return false;
	}

i have that check at the begining to make sure the file is opening and it says that it is

has anyone seen or heard anything like this before... if so throw out a tip or give me a direction to look in... please. It would be greatly appreciated

Thanks

  • 2 Contributors
  • 2 Replies
  • 203 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by drock9975

Dani AI

Generated

A few likely causes explain why the same binary reads correctly in Debug but not in Release. As noted, using sizeof on a char* yields the pointer size, not the string length — that alone can make your diagnostic output meaningless. More commonly, differences between builds point to undefined behavior (uninitialized variables, buffer overruns, corrupted stack), or to path/working-directory differences so the program opens a different file than you expect.

Quick, practical checks to narrow it down:

  • Log the fully resolved filename and its length (so you know which file was actually opened).
  • Confirm the working directory used by the Release run; Visual Studio sometimes uses different working directories for Debug vs Release.
  • Validate every binary read: check gcount() or the stream state after read() and refuse to interpret partial reads.
  • Add a short magic/header and version number to your particle files so a wrong-file read fails fast.

Example diagnostics (Windows + C++):

char full[MAX_PATH];
GetFullPathNameA(fname, MAX_PATH, full, nullptr);
std::ofstream diag("particle_problem.txt", std::ios::trunc);
diag << "resolved: " << full << " len=" << strlen(fname) << '\n';

Example safe read check:

int32_t value = 0;
file.read(reinterpret_cast<char*>(&value), sizeof value);
if (file.gcount() != sizeof value) {
    // log and fail: partial/invalid read
}

Additional suggestions: initialize structures before reading, switch char* parameters to std::string to avoid lifetime issues, compile the Release build with optimizations reduced or runtime checks enabled to reproduce the bug, and run a memory checker (AddressSanitizer / Dr. Memory / VS heap checks). Given the symptoms you described to , the most likely root is memory corruption or a wrong/resolved path — start by logging the exact path and validating file headers before consuming binary data.

Recommended Answers

All 2 Replies

Member Avatar for Dave Sinkula

I didn't look too closely, but this sticks out.

problem.write(fileName, sizeof(fileName));

Wouldn't you want the length of the string rather than the size of a pointer?

Member Avatar for drock9975

yeah, but that is neither here nor there...

file.open(fileName, ios_base::in | ios_base::binary);

this is not opening the correct file for whatever reason... i just tossed that check in right before i posted here to see if it got past the is_open check(which it does)...

i'm just curious if anyone has had a problem similar to mine

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.