Sign in to follow this  
Ratslayer

std::ifstream destructor freaks out.

Recommended Posts

Hello, I'm trying to read a binary file I have written, but, after reading it, the destructor of std::ifstream gives me an access violation error 0xC0000005.

Here is the relevant code:

BBReader::BBReader(string file_name)
{
std::ifstream filestr;
int size;
//open file
filestr.open(file_name, std::ios::in | std::ios::binary);
if (!filestr.is_open())
throw(string("Failed to open stream from ")+file_name);
//read the file into the buffer
size=(int)(filestr.tellg());
char* buffer=new char[size];
//filestr.seekg(0, std::ios::beg);
filestr.read(buffer, size);
filestr.close();

//private char* Buffer
this->Buffer=Buffer;
//private int bufferSize
bufferSize=size;
//private char* CurPtr
CurPtr=Buffer;
}


I couldn't find anything on the internet about that, the call stack tells me:
> msvcr100d.dll!operator delete(void * pUserData) Line 52 + 0x3 bytes C++

Anyone can help? I've used this code before and it worked.

Share this post


Link to post
Share on other sites
On a different note: don't just throw anything, like an std::string. std::exception and its subclasses are there for a reason. If no better alternative presents itself, use an std::runtime_error.

Share this post


Link to post
Share on other sites
As far as the throws go, I agree that throwing stuff around isn't the best practice, but this is a small program and I've decided to cut corners for once. I guess I'll have to fix this afterwards.

I changed the code to:

BBReader::BBReader(string file_name)
{
std::ifstream filestr;
int size;
//open file
filestr.open(file_name, std::ios::binary);
if (!filestr.is_open())
throw(string("Failed to open stream from ")+file_name);
//read the file into the buffer
filestr.seekg(0, std::ios::end);
size=(int)(filestr.tellg());
filestr.seekg(0, std::ios::beg);
char* buffer=new char[size];
filestr.read(buffer, size);
filestr.close();

this->Buffer=Buffer;
bufferSize=size;
CurPtr=Buffer;
}




As far as I can tell, now it's supposed to give me the right size, since I move the pointer to the end. However, the error still persists, and the call stack remains the same. Any thoughts on this?

Share this post


Link to post
Share on other sites
First, don't get into the "I guess I'll have to fix this afterwards" mode of thinking to start with. It practically never does get fixed and may end up in production code. Which is not a problem for me unless it's production code I have to use in compiled form, or even worse, debug myself. That happens unfortunately far too often, so I really get annoyed when I see something like that which can cost you an hour or two of annoyance because someone decided to save a second or less.

Second, you appear to just discard the buffer variable and instead have a self-assignment as this->Buffer = Buffer. You should be getting a warning about that though and warnings are your friend. You should also check if size is 0, I'm not sure what the standard says about allocating an array of length 0.

Deleting the probably uninitialized Buffer pointer later on could cause all kinds of havoc though (I don't expect you initialized it to 0?), although I cannot see an immediate reason for the std::ifstream destructor to cause problems. Are you sure it is actually the one causing problems?

Share this post


Link to post
Share on other sites
Omg. This is as lame of an error as one can get. Somehow I didn't get a warning on this one, thus I couldn't find the error. As far as I'm concerned about the exceptions, I hear you, and I do aknowledge that the way I'm doing it is pretty brainless, but I really can not afford changing it right now. My assignment is due in a few hours and this is working, but once I am free, figuring out the right way to use exceptions in C++ is on my to-do list.

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