By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,364 Members | 1,267 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,364 IT Pros & Developers. It's quick & easy.

writing to a file prior to system crash

P: n/a
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.wSecon d+systime.wMilliseconds/1000.0,line);
fclose(file);
}

Oct 17 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
be*****************@gmail.com wrote:
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.
Oct 17 '06 #2

P: n/a
On 17 Oct 2006 14:30:43 -0700, be*****************@gmail.com wrote in
comp.lang.c:
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.wSecon d+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 news:comp.os.ms-windows.programmer.win32 as a good one.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Oct 17 '06 #3

P: n/a

be*****************@gmail.com wrote:
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.

Oct 18 '06 #4

P: n/a
be*****************@gmail.com writes:
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.

Oct 18 '06 #5

P: n/a
be*****************@gmail.com wrote:
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.
fprintf(file, "%2d:%02d:%06.3lf ::
%s\n",systime.wHour,systime.wMinute,systime.wSecon d+systime.wMilliseconds/1000.0,line);
fclose(file);
}
--
Simon.
Oct 18 '06 #6

P: n/a
On Wed, 18 Oct 2006 16:30:14 +0200, Richard <rg****@gmail.comwrote:
>be*****************@gmail.com writes:
>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.
That's precisely what he did. You must not have seen the original
post.
>I would be
surprised if the close didn't commit the data to disk.

fclose is Ansi C.
--
Al Balmer
Sun City, AZ
Oct 18 '06 #7

P: n/a
Richard wrote:
be*****************@gmail.com writes:
>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.
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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Oct 18 '06 #8

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Richard wrote:
>be*****************@gmail.com writes:
>>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.

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.
Oct 18 '06 #9

P: n/a
On Wed, 18 Oct 2006 11:01:17 -0400, CBFalconer <cb********@yahoo.com>
wrote:
>Richard wrote:
>be*****************@gmail.com writes:
>>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.

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.

--
Al Balmer
Sun City, AZ
Oct 18 '06 #10

P: n/a
Al Balmer <al******@att.netwrites:
On Wed, 18 Oct 2006 11:01:17 -0400, CBFalconer <cb********@yahoo.com>
wrote:
[...]
>>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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #11

P: n/a
On Wed, 18 Oct 2006 11:01:17 -0400, CBFalconer <cb********@yahoo.com>
wrote:
>Richard wrote:
>be*****************@gmail.com writes:
>>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.

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.

--
jay
Oct 19 '06 #12

P: n/a
On 17 Oct 2006 14:30:43 -0700, be*****************@gmail.com wrote:
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
Oct 30 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.