writing to a file prior to system crash

  • Thread starter benjamin.krulewitch
  • Start date
B

benjamin.krulewitch

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs. I us my BKprintLog function (see below) to write
information into a log file. The problem is, i'm not confident that
information i write to the log gets saved onto the hard drive before
the crash occurs.

My understanding of hard drives and OS are that because hard drives are
so slow, that when you write to the harddrive, that information is put
into a buffer, control is returned to the program, and then the
information is saved to permanent storage in the near future. This
application is running on Windows.

Is there any way to guarantee that before my function returns, anything
written to the hard drive is Actually on the hard drive?

The data I'm getting seems to support my concern, as according to the
logs, the crash is occuring at different places each time, and
sometimes, the log file doesn't even get anything written into it
before a crash.


ben



void BKprintLog(char * line) {
FILE * file;
const char * FILENAME = "C:\\log_file.txt";
SYSTEMTIME systime;

GetSystemTime(&systime);
file = fopen(FILENAME,"a+");
fprintf(file, "%2d:%02d:%06.3lf ::
%s\n",systime.wHour,systime.wMinute,systime.wSecond+systime.wMilliseconds/1000.0,line);
fclose(file);
}
 
J

jmcgill

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs.

Many operating systems (including Windows) provide facilities for
synchronous file I/O. Ask your question in a newsgroup appropriate to
your OS and you may actually stand a chance of getting answers.
 
J

Jack Klein

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs. I us my BKprintLog function (see below) to write
information into a log file. The problem is, i'm not confident that
information i write to the log gets saved onto the hard drive before
the crash occurs.

The fact that you program "crashes" the computer, almost certainly
means that the program itself produces some sort of undefined
behavior.
My understanding of hard drives and OS are that because hard drives are
so slow, that when you write to the harddrive, that information is put
into a buffer, control is returned to the program, and then the
information is saved to permanent storage in the near future. This
application is running on Windows.

The C standard specifies nothing at all about hard drives, or any
other physical device. The input and output is abstracted into FILE *
streams. All the interface with the actual disks or other devices is
completely up to the underlying platform.
Is there any way to guarantee that before my function returns, anything
written to the hard drive is Actually on the hard drive?

There is certainly no way defined by the C language to do this.
The data I'm getting seems to support my concern, as according to the
logs, the crash is occuring at different places each time, and
sometimes, the log file doesn't even get anything written into it
before a crash.
void BKprintLog(char * line) {
FILE * file;
const char * FILENAME = "C:\\log_file.txt";
SYSTEMTIME systime;

GetSystemTime(&systime);
file = fopen(FILENAME,"a+");
fprintf(file, "%2d:%02d:%06.3lf ::
%s\n",systime.wHour,systime.wMinute,systime.wSecond+systime.wMilliseconds/1000.0,line);
fclose(file);
}

Even your logging function contains non standard functions and data
types. There's also a potential standard C library problem in the
fact that you don't check to see if the fopen() succeeded. If it does
not, your pointer 'file' is NULL, and passing it to fprintf() causes
undefined behavior and could be causing your problem.

If there is a system specific extension that does what you want, you
would need to ask in a platform specific groups about it. I would
suggest as a good one.
 
S

Simon Biber

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs. I us my BKprintLog function (see below) to write
information into a log file. The problem is, i'm not confident that
information i write to the log gets saved onto the hard drive before
the crash occurs.

My understanding of hard drives and OS are that because hard drives are
so slow, that when you write to the harddrive, that information is put
into a buffer, control is returned to the program, and then the
information is saved to permanent storage in the near future. This
application is running on Windows.

Is there any way to guarantee that before my function returns, anything
written to the hard drive is Actually on the hard drive?

The best you can do in standard C is to flush the stream. Since your
function below actually closes the file, the stream is certainly flushed
as part of that process. So, there's not a whole lot more you can do.

Most operating systems provide additional features such as a
"synchronise" function to ensure all buffers are written to disk. The
details are system-specific and so are not discussed in this newsgroup.
The data I'm getting seems to support my concern, as according to the
logs, the crash is occuring at different places each time, and
sometimes, the log file doesn't even get anything written into it
before a crash.


ben



void BKprintLog(char * line) {
FILE * file;
const char * FILENAME = "C:\\log_file.txt";
SYSTEMTIME systime;

GetSystemTime(&systime);
file = fopen(FILENAME,"a+");

What happens if the fopen fails? You try to print to the file anyway!
This might even be the source of your crashes, and it would explain why
there was nothing in the file. Always check the result of fopen is not
null before trying to use the file.
 
A

Ancient_Hacker

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs.

The C standard is mostly mum about real-time situations like this.

You're correct that files tend to be buffered, so you may not see
everything in the actual file.

often it helps to write to stderr, which is not buffered. and/or
redirect stderr to a serial port, which are rarely buffered at that
level. or call fflush after each write.

better yet, run your program, if possible, on a more stable platform,
like LInux or Windows NT-- a system with memory protection.
 
R

Richard

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs. I us my BKprintLog function (see below) to write
information into a log file. The problem is, i'm not confident that
information i write to the log gets saved onto the hard drive before
the crash occurs.

My understanding of hard drives and OS are that because hard drives are
so slow, that when you write to the harddrive, that information is put
into a buffer, control is returned to the program, and then the
information is saved to permanent storage in the near future. This
application is running on Windows.

Is there any way to guarantee that before my function returns, anything
written to the hard drive is Actually on the hard drive?

Just one simple thing to try ,did you try closing (fclose) the log file? Write
your own log function and call that, open and close the file therin.I would be
surprised if the close didn't commit the data to disk.

fclose is Ansi C.
 
C

CBFalconer

Richard said:
Just one simple thing to try ,did you try closing (fclose) the log
file? Write your own log function and call that, open and close the
file therin.I would be surprised if the close didn't commit the
data to disk.

fclose is Ansi C.

You didn't bother reading his article, and slipped the relevant
code out. He is doing all that. I don't know if Windows has a
similar command to sync to flush the actual buffers, but his code
should write the info out if he waits a reasonable time (5 to 10
secs). Of course he is using Windoze, so anything can happen.

What is missing from his code is a call to fflush(). This should
guarantee moving the data from the programs buffers to the systems
buffers.
 
A

Al Balmer

Just one simple thing to try ,did you try closing (fclose) the log file? Write
your own log function and call that, open and close the file therin.

That's precisely what he did. You must not have seen the original
post.
 
R

Richard

CBFalconer said:
You didn't bother reading his article, and slipped the relevant

Not that I didn't bother - I guess I missed it.
code out. He is doing all that. I don't know if Windows has a

My error : someone already pointed that out.
 
A

Al Balmer

You didn't bother reading his article, and slipped the relevant
code out. He is doing all that. I don't know if Windows has a
similar command to sync to flush the actual buffers, but his code
should write the info out if he waits a reasonable time (5 to 10
secs). Of course he is using Windoze, so anything can happen.

What is missing from his code is a call to fflush(). This should
guarantee moving the data from the programs buffers to the systems
buffers.

fclose() will do the flush.
 
K

Keith Thompson

Al Balmer said:
[...]
What is missing from his code is a call to fflush(). This should
guarantee moving the data from the programs buffers to the systems
buffers.

fclose() will do the flush.

And neither fclose() nor fflush() guarantees that the data is actually
written to disk. There could be buffering at the OS level, invisible
to the C runtime library.

There's likely to be some system-specific way to flush data all the
way to the disk (or other external device).
 
J

jaysome

You didn't bother reading his article, and slipped the relevant
code out. He is doing all that. I don't know if Windows has a
similar command to sync to flush the actual buffers, but his code
should write the info out if he waits a reasonable time (5 to 10
secs). Of course he is using Windoze, so anything can happen.

And anything can happen if he's using Linux or Mac OS or any other
platform, by virtue of your comment below.
What is missing from his code is a call to fflush(). This should
guarantee moving the data from the programs buffers to the systems
buffers.

Yes.
 
D

Dave Thompson

I'm debugging an issue with a C program that causes the computer to
crash, and I'm attempting to log information immediately before the
crash occurs. I us my BKprintLog function (see below) to write
information into a log file. The problem is, i'm not confident that
information i write to the log gets saved onto the hard drive before
the crash occurs.
Do you really mean "the computer" or just your program/process?

As others have already noted, C allows and pretty strongly encourages
buffering within stdio, almost always in userland, which 'must' be
flushed at fflush or fclose, and you have the latter. I put 'must' in
quotes because parts of the C Standard dealing with the environment
external to the program are formally out of scope and can't be stated
precisely, but this is clearly the intent and overwhelmingly the
convention. This flush should definitely 'push' the data to the OS;
whether the OS buffers outside of your program may vary.
My understanding of hard drives and OS are that because hard drives are
so slow, that when you write to the harddrive, that information is put
into a buffer, control is returned to the program, and then the
information is saved to permanent storage in the near future. This
application is running on Windows.
If you mean a 'modern' Windows (NT or 2k or later) it should NOT crash
no matter how badly a userland program screws up, and your data should
get written, even if not instantly. Well, except for the sillly
CSRSS(sp?) bug, but that's fixed now. And I have once or twice seen
screwups bad enough to kill explorer, which means you can't start new
tools but only use ones that are already running. I always leave a
'command' (console) window off to the side just in case.
Is there any way to guarantee that before my function returns, anything
written to the hard drive is Actually on the hard drive?
Certainly no standard way; if there is a Windows specific way you
would need a Windows group or site to learn about it. But as above, I
doubt that is really needed.
The data I'm getting seems to support my concern, as according to the
logs, the crash is occuring at different places each time, and
sometimes, the log file doesn't even get anything written into it
before a crash.
I suspect a more likely problem is that you are corrupting userland
data that your C runtime depends on, so the stdio calls in your
logging routine either don't work at all or not correctly. If so, you
might do better using lower-level system-specific I/O facilities,
which in Windows would I believe be CreateFile, WriteFile, etc., and
again you want a system-specific place to learn about these.

If you really are crashing the OS and can't get it to flush to real
disk, you might consider instead logging over a comms port or network
connection if you have such working on your system to another machine.
If you send the data and wait for an 'end-to-end' application level
acknowledgement, you can be certain that your data is safe. This will
probably be much slower than disk logging however; if you are doing a
significant volume of this it will slow down your program, which may
or may not affect the bug you are trying to find.

- David.Thompson1 at worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top