Thread: File Output Behavior During Crash

Hello,

I have a question regarding file output using <stdio.h>. First, let me give a bit of background on what I am doing.

I am using extensive logging in a game modification to help find crashes. I am currently logging every function call and the number of writes is around 6,000 per second. As this is meant to track the last function called before a crash, the log must always be up to date when the game crashes. Currently, I am using fflush after every write to ensure this.

My problem is that calling fflush 6,000 times per second is very slow. If I have queued writes (due to not calling fflush) and my program crashes, will they still get written properly or will they be lost? I am not concerned if the OS crashes, only the program.

They will probably be lost, since the program crashes. So it is not a good idea.

You could try saving the data in the memory, not in a file. Like in an array. Then at one point saving everything in a file all at once, then store everything in the memory etc etc. Don't write/read 6k/s in a file. For starters it should be really slow.
In a way you will use an extra buffer defined by you to be big enough.

Now, if you mean that your program crashes for other reasons, because for example your game crashes, so it reads from nowhere, you will have to check before reading from the game. If the read fails the program should close() the file after writing everything that is needed and exit.

I see. When you say memory, you mean shared memory? I suppose that would work better (having a separate process to do the actual writing), I'll try that.

Originally Posted by Salem

Why not run the code in a debugger, and just wait for it to crash?

The crashes are not easily reproducible and likely caused by a combination of race conditions, so I need people without a development environment to give me the details of their crashes.

Originally Posted by Salem

But your attempt at logging has already changed the problem.
Changed it quite a lot it would seem.

While you are technically correct, I have not found the amount of crashes to increase or decrease after adding my logging (which I wrote so that it can be completely removed with compiler flags). The logging has been in place for several weeks and has led to the fixing of several bugs so far, so I feel it is and has been a valuable asset.

Originally Posted by Salem

If you lack a solid design, which documents how resources are shared, and who has ownership of things (and how that ownership might change), then I feel all you're doing is putting sticking plaster on a patient with multiple stab wounds.

I understand your criticism here, though let me explain my situation a bit more.

As I mentioned in my first post, this is actually a game modification. I (and the others I am working with) do not have full access to the source code of the game we are working with. We are working with an SDK that is not well documented, either with comments or design docs. This has led to discovering some things the hard way.

Is this optimal? No. Is it impossible? Also no.

So we could either try our best with what we have or just give up. We chose the former.

Some of the errors have just been mistakes like forgetting to check a pointer that only sometimes causes a problem. If you never make a mistake when coding then I salute you, but I am unfortunately not that good.

This log has helped us and is continuing to help us find errors. The only problem is that it slows down performance by a large amount, though not enough that it becomes unplayable or that all the errors disappear.

Therefore I will continue with my solution because it is working for me and I do not see a better one at the moment.

Originally Posted by matsp

What sort of crash? What OS?

Can you build a trap that catches the fault itself, and flushes the file before you exit? In Windows that would be a __try block (if you have "enhanced exception handling" enabble or whatever it's called), in Linux it would be a signal handler and a longjmp to get the system back to normal - it may not work 100%, but probably better than what you have right now.

This is on Windows. I don't think it will be easy to trap in a try block, other than adding try/catch to every function...which I suppose is possible, with a little elbow grease.

Unfortunately I don't have access to the main function (Our code compiles to a DLL that is loaded), which is what I meant when I said it would not be easy to trap in a single try/catch block.

Originally Posted by matsp

Ok, so you may be able to set up a signal() handler for SIGSEGV, and use that to flush the file and exit the application.

http://msdn.microsoft.com/en-us/libr...12(VS.71).aspx

--
Mats

This is perfect, thank you very much for pointing me to this Mats! I just did some testing with simulated crashes and it is working just as I'd like.