In consistent "Access violation reading location" while writing to binary file using fstream

I'm attempting to adapt a piece of code to take the FFT of some input data. Everything goes fine taking the transform. My problem occurs when I try to write the transform to a binary file at which point I get:

Unhandled exception at 0x68d0ca24 (msvcr100d.dll) in FFT.exe: 0xC0000005: Access violation reading location 0x00161000.

Weirdest thing is, it doesn't happen every time I compile and run the program. About every third time it runs just fine and saves the data to the file.

#include <iostream>
#include <fstream>
#include <cmath>
#include <cstdlib>

#include "dft/FFT.h"
#include "ffft/FFTReal.h"

int main ()
{
    using namespace std;
    const char* dataFile = "C:/users/gad18/documents/temp/testData.dat";
    const char* transformFile = "C:/users/gad18/documents/temp/DFTtestOutput.dat";
    int length;
    off_t size;

    fstream inFile;
inFile.open( dataFile, ios_base::in | ios_base::binary );
if ( ! inFile.is_open() )
{
    cout << "Error opening " << dataFile << " for reading." << endl;
    cout << "Terminating process." << endl;
    cin.get();
    exit( EXIT_FAILURE );
}


cout << "Reading from " << dataFile << endl;
inFile.seekg( 0, ios_base::end );
size = static_cast <off_t> ( inFile.tellg() );
inFile.seekg( 0, ios_base::beg );
length = size / sizeof( float );

float* buffer = new float[ length ];
float* F = new float [length ];

inFile.read( (char*) buffer, length * sizeof( float ) );
inFile.close();

cout << size << " bytes read in." << endl;
cout << length << " float elements read into memory." << endl;

cout << "Press return key to creat DFT object..." << endl;
cin.sync();
cin.get();

cout << "Creating DFT object of length " << length << " points." << endl;

dft::FFT dft_object( length );
ffft::FFTReal<float> ffft_object( length );

int bits_out = dft_object.get_bits();
cout << "Successfully created DFT object with " << bits_out << " bit depth." << endl;

cout << "Press return key to attempt fast Fourier transform of data..." << endl;
cin.sync();
cin.get();

dft_object.compute_FFT( F, buffer );

cout << "Press return key to save transform data..." << endl;
cin.sync();
cin.get();

fstream outFile;
outFile.open( transformFile, ios_base::out | ios_base::trunc | ios_base::binary );
if ( ! outFile.is_open() )
{
    cout << "Error opening " << dataFile << " for writing." << endl;
    cout << "Terminating process." << endl;
    cin.get();
    exit( EXIT_FAILURE );
}
else
{
    outFile.write( (char*) &F, length * sizeof( float ) );
    size = outFile.tellg();
    cout << "Wrote " << size << " bytes to " << transformFile << endl;
    outFile.close();
}

delete [] buffer;
delete [] F;

cout << "Press return key to continue...";
cin.sync();
cin.get();
return 0;
} // int main()

My apologies if this is not the proper way to include code in a question (first post here).

The exception seems to consistently occur at line 202 of streambuf (maybe that helps?).

What's really throwing me off is that it is seemingly random in occurrence and since this is the first time I've run into this problem I'm not sure where to even start looking for the bug. Based on other posts about this开发者_如何转开发 exception, it seems there may be a problem with my use of pointers?

Any help as to a solution or how to handle running down there bugs would be much appreciated.

Thank you, Greg

I believe the problem is here:outFile.write( (char*) &F, length * sizeof( float ) );

I think what you want is:

    outFile.write( (char*) F, length * sizeof( float ) );

You are dumping memory starting at the address of the pointer, not of the address stored in the pointer. If these two addresses have the right relationship in memory, the write will work, although some of the data in the file will be wrong. But the behavior is unpredictable, and can cause a crash.

If I were you, I would think about a file format that is more robust than a dump of the memory representing your output array--

Since you're on a Windows box, try downloading Application Verifier from MSDN. (Sorry, typing this from my WP7 so I don't have the link handy). With pageheap and the basic checks enabled, it may pinpoint exactly the problem.