I am a java programmer trying to understand a c++ oddity that I ran into. My c++ program writes a few MB of data using ofstream. Just before the program ends I close the ofstream. However when the program terminates, the amount of free memory on my linux box has decreased by the size of the data that was written. The memory remains lost until the file is deleted. Here is a sample of how I use ofstream:


In my constructor, I have:
ofstream tfile("../../tmp/outputfile.txt", std::ios::app);

a number of prints using tfile occur that are similar to the following line:

tfile << track->GetTrackID() << '\t' << track->GetParentID() << '\t' << pName << '\t';

In the destructor, I have:

tfile.close();

Any ideas would be appreciated!

Recommended Answers

All 6 Replies

It looks to me that you are reading data into a buffer that does not get deleted at the end. Check your code for the ever so elusive buffer.

Thanks for the quick answer! How does one typically delete/find the buffer? tfile->delete was my first guess, but it causes segmantation faults since the ofstream constructor was not called...

The problematic snippet of code writes the interesting data from my monte carlo sim.

Thanks for the quick answer! How does one typically delete/find the buffer? tfile->delete was my first guess, but it causes segmantation faults since the ofstream constructor was not called...

The problematic snippet of code writes the interesting data from my monte carlo sim.

Can you post that code snippet? It might help if our members had that to look at.

I am not a Java person, but in C++ you best look at something like "new" and the potentially missing "delete". Here is a typical code segment (commented to the hilt):

// Allocate memory
  buffer = new char[length];

  // Read data as a block
  is.read(buffer, length);

  // Close file
  is.close();

  // Print data
  cout << buffer << endl;

  // Free memory
  delete []buffer;

I have a RunAction class which has the following global line:

std::ofstream tfile("../../tmp/outputfile.txt", std::ios::app);


RunAction::~RunAction() {
tfile.close();
}

A second class SD has the following global line:

extern ofstream tfile;


SD::ProcessHits(G4Step* step,G4TouchableHistory* ROhist) {
 G4Track* track;
if(step != NULL)
track = step->GetTrack();
else
track = NULL;


G4double edep = 0;
if(step != NULL)
edep = step->GetTotalEnergyDeposit();


bool write = false;
G4int parentID = track->GetParentID();
G4String pName = (track->GetDefinition())->GetParticleName();
G4double kEnergy = track->GetKineticEnergy();
G4double dEnergy = step->GetTotalEnergyDeposit();
G4String volName = track->GetVolume()->GetName();


if((track != NULL) && (step != NULL) && goodEvent) {
// Output to text file.
if((track->GetDefinition()) != NULL)
if((track->GetVolume()) != NULL)
if((step->GetPostStepPoint()) != NULL)
if((step->GetPostStepPoint()->GetProcessDefinedStep()) != NULL)
tfile << track->GetTrackID() << '\t'
<< track->GetParentID() << '\t'
<< pName << '\t'
<< track->GetCurrentStepNumber() << '\t'
<< kEnergy << '\t'
<< dEnergy << '\t'
<< step->GetStepLength() << '\t'
<< track->GetTrackLength() << '\t'
<< track->GetVolume()->GetName() << '\t'
<< step->GetPostStepPoint()->GetProcessDefinedStep()->GetProcessName() << '\t'
<< track->GetPosition().x() << '\t'
<< track->GetPosition().y() << '\t'
<< track->GetPosition().z() << '\t'
<< track->GetMomentumDirection().x() << '\t'
<< track->GetMomentumDirection().y() << '\t'
<< track->GetMomentumDirection().z() << '\t'
<< track->GetGlobalTime() << '\t'
<< step->GetPreStepPoint()->GetKineticEnergy() << std::endl;
}
}

A couple of other classes use tfile in the same way as the SD class.

My working hypothysis has changed. I now believe that c++ is NOT memory leaking but instead linux is storing the file in cached memory even after the program has terminated. Deleting the file then forces linux to clear it from cached memory...Thanks for your help!

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.