ofstream memory bashing

I am not sure if this should go in the linux or C++ section, but...

I am working on a program that creates a ofstream and writes to it. Anyway, upon tracing through the program, we found that when ofstream was called, it trashed some of the memory (and the contents of a char array). Does anyone have any ideas about this?

ofstream outFile("filename.dat",ios::binary);


it is on amd64 dual core running suse 10.1


thanks...

This line most definitely doesn't trash anything. We need more code. But most likely, the issue is too complex to diagnose remotely.

And since, so far, there's nothing Linux-specific here, it should be in C++.

Moved.

I know it doesn't, however I can watch as the data in memory changes when the call returns. I cannot trace through the sys call to see what is happening.

As far as the code goes, I really cannot post it. Still, I fail to see how anything else should matter if while going through the debugger, the memory contains one thing, the ofstream call happens and returns and the memory now contains something else.

I am somewhat novice so I would accept any explaination to the contrary...

All that being said, what else could it be?

Thanks all for your time...

Well if you've generally made a mess of memory, then any part of your code could look like it's messing with the data belonging to any other part of the code.

You're observing an effect, but when it comes to memory corruption, this is very seldom the cause.

You could try
gcc -g prog.c -lefence

Then
gdb a.out
run

With any luck, that should trap on the first instruction which does something 'iffy' with allocated memory (like using it after being freed or stepping off the end).

std::ofstream by default truncates or overwrites a previously existing file. Use std::ios::app

Quote:

---

Originally Posted by Salem

Well if you've generally made a mess of memory, then any part of your code could look like it's messing with the data belonging to any other part of the code.

You're observing an effect, but when it comes to memory corruption, this is very seldom the cause.

You could try
gcc -g prog.c -lefence

Then
gdb a.out
run

With any luck, that should trap on the first instruction which does something 'iffy' with allocated memory (like using it after being freed or stepping off the end).

---

I see what you are saying...I will give it a try. Thanks for you help.