Access violation reading location issue

[dwillatberwick]

I am using Visual Studio Express C++ 2010 edition on Windows 7 and I am having trouble trying to debug an Access violation reading location error when a class object, that opens and closes a file, destructs.

I don't know if I am using fstream imporperly when I want to open a close a file within a class, and use that class to open different files in the main program.

I recieve the following error output when the program crashes:

First-chance exception at 0x6081aa1e (msvcp100d.dll) in test_fstream_use.exe: 0xC0000005: Access violation reading location 0x00000004.
Unhandled exception at 0x6081aa1e (msvcp100d.dll) in test_fstream_use.exe: 0xC0000005: Access violation reading location 0x00000004.

This is the call stack from the debugger:

> msvcp100d.dll!std::basic_iostream<char,std::char_traits<char> >::~basic_iostream<char,std::char_traits<char> >() Line 982 + 0x2e bytes C++
test_fstream_use.exe!std::basic_fstream<char,std::char_traits<char> >::~basic_fstream<char,std::char_traits<char> >() Line 1303 + 0x20 bytes C++
test_fstream_use.exe!std::basic_fstream<char,std::char_traits<char> >::`vbase destructor'() + 0x2e bytes C++
test_fstream_use.exe!surf_import::~surf_import() Line 22 + 0x36 bytes C++
test_fstream_use.exe!main() Line 12 + 0x1c bytes C++
test_fstream_use.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
test_fstream_use.exe!mainCRTStartup() Line 371 C

Following is my code:

stdafx.h

//stdafx.h
#pragma once

#include "targetver.h"

#include <stdio.h>
#include <iostream>
#include "surf_import.h" 

test_fstream_use.cpp

//test_fstream_use.cpp
#include "stdafx.h"

int main()
{
	surf_import surfdata;
	surfdata.fname = "test.sur";
	surfdata.import();
	return 0;
}

surf_import.h

//surf_import.h
#ifndef _IMPORT_SURF_H
#define _IMPORT_SURF_H

#include <fstream>
#include <string>

class surf_import
{
private:
	std::fstream sur_file;

public:
	surf_import(void);
	~surf_import(void);
	void import();
	std::string fname;
};

#endif 

surf_import.cpp

//surf_import.cpp -Edit in bold after Chervil's reply-
#include "StdAfx.h"
#include "surf_import.h"

surf_import::surf_import(void){};

void surf_import::import()
{
	sur_file.open(fname.c_str(), std::ios::in | std::ios::binary | std::ios::ate);
	if (sur_file.is_open())
	{
		std::cout<<"file is open..."<<std::endl;
		/*code if open*/
	}
	sur_file.close();
}

surf_import::~surf_import(void)
{
        std::cout<<"surf import destroyed!"<<std::endl;
}

My console output shows:

file is open...
surf import destroyed!

I am new to C++ and I am sure there is a simple explanation but I am having trouble searching the web for equivalent issues that pertains to opening and closing files. Advice is greatly appreciated.

[Chervil]

I'm not sure why you get that error.
However, this line
sur_file.open(fname, std::ios::in | std::ios::binary | std::ios::ate);
should be
sur_file.open(fname.c_str(), std::ios::in | std::ios::binary | std::ios::ate);

I'm surprised your code would compile without this change.

[dwillatberwick]

Thank you. I made that edit you suggested just to see if by chance that may have caused an issue. I rebuilt the application and still get the same errors with the same console output.

[Peter87]

Chervil wrote:

I'm surprised your code would compile without this change.

In C++11 open has been overloaded to accept std::string as argument so it will work on an up to date compiler.

[Chervil]

Thanks Peter87.

[dwillatberwick]

So I deleted the default property sheets used for VS 2010 Express because I had recently explored the use of gtkmm and restarted VS 2010 Express. I copy pasted the codes into a new project and now the code compiles and runs fines without any access violation reading location errors.

The gtkmm installation (following the procedure on gtkmm) required some different build properties that gtkmm makes available to import. I thought the changes would only be for that project, but it seems to have had over-written the default propert sheets and maybe whatever changes made there was interfering with proper compilation.

I will see if I can duplicate this again by re-importing the gtkmm property sheets, and if it happens again I'll post something to gtkmm.