I'm running an application on an embedded device running Linux (2.6.21
kernel) . I've found that when the CPU load gets really high on the
device, output to a file stream sometimes fails.

When I turn on exceptions, the what() method from the exception that
gets thrown just tells me that there's a basic_ios::clear error, and
I've verified that errno is 0.

Does anyone have any suggestions about what I can do?

I thought about retrying, since subsequent writes to that stream
apparently work. However, my concern is that I don't know the nature
of the failure. Say I attempted to do a write of 10 bytes from a
character buffer. Is there any way to tell if it failed and none of
the bytes got written out, 2 of the bytes, or 9?

The file system that my ofstream is writing out to is actually a
ramdisk partition (tmpfs file system).

I don't mind retrying, if necessary, but I need the output of the
stream to be correct, which means I need to know from where I should
be retrying.

Any ideas?

"dont_spam_me" <joe.anon09@gmail.com> write:
>
> I'm running an application on an embedded device running Linux (2.6.21
> kernel) . I've found that when the CPU load gets really high on the
> device, output to a file stream sometimes fails.
>
> When I turn on exceptions, the what() method from the exception that
> gets thrown just tells me that there's a basic_ios::clear error, and
> I've verified that errno is 0.
>
> Does anyone have any suggestions about what I can do?
>
> I thought about retrying, since subsequent writes to that stream
> apparently work. However, my concern is that I don't know the nature
> of the failure. Say I attempted to do a write of 10 bytes from a
> character buffer. Is there any way to tell if it failed and none of
> the bytes got written out, 2 of the bytes, or 9?
>
> The file system that my ofstream is writing out to is actually a
> ramdisk partition (tmpfs file system).
>
> I don't mind retrying, if necessary, but I need the output of the
> stream to be correct, which means I need to know from where I should
> be retrying.
>
> Any ideas?

It seems to be either a memory low issue or a timeout issue.
As next I would try it with FILE*
and add a fflush(fp) immediately after the writing.
If the error still happens then even go one
level deeper and try it with _write(fd) ...
Then you can decide better...
BTW, don't forget to close the file first before trying the above things...

On Jul 1, 6:13pm, "Adem24" <ade...@adem24adem24.org.invalid> wrote:
> "dont_spam_me" <joe.ano...@gmail.com> write:
>
>
>
>
>
>
>
> > I'm running an application on an embedded device running Linux (2.6.21
> > kernel) . I've found that when the CPU load gets really high on the
> > device, output to a file stream sometimes fails.
>
> > When I turn on exceptions, the what() method from the exception that
> > gets thrown just tells me that there's a basic_ios::clear error, and
> > I've verified that errno is 0.
>
> > Does anyone have any suggestions about what I can do?
>
> > I thought about retrying, since subsequent writes to that stream
> > apparently work. However, my concern is that I don't know the nature
> > of the failure. Say I attempted to do a write of 10 bytes from a
> > character buffer. Is there any way to tell if it failed and none of
> > the bytes got written out, 2 of the bytes, or 9?
>
> > The file system that my ofstream is writing out to is actually a
> > ramdisk partition (tmpfs file system).
>
> > I don't mind retrying, if necessary, but I need the output of the
> > stream to be correct, which means I need to know from where I should
> > be retrying.
>
> > Any ideas?
>
> It seems to be either a memory low issue or a timeout issue.
> As next I would try it with FILE*
> and add a fflush(fp) immediately after the writing.
> If the error still happens then even go one
> level deeper and try it with _write(fd) ...
> Then you can decide better...
> BTW, don't forget to close the file first before trying the above things....- Hide quoted text -
>
> - Show quoted text -

The problem though is that I'm not sure if any of the bytes from my
original ostream write actually wrote out. I can retry using any
call, but I need to know what to write out.

Is there a way to find this out? Or is it all or nothing? Unlike the
write() c function, which returns the number of bytes written, the
return value for ostream::write() is the this pointer.

Does this mean I simply can't use c++ streams for file output unless I
do it byte by byte?

On Jul 2, 2:18 am, dont_spam_me <joe.ano...@gmail.com> wrote:
> I'm running an application on an embedded device running Linux
> (2.6.21 kernel) . I've found that when the CPU load gets
> really high on the device, output to a file stream sometimes
> fails.

> When I turn on exceptions, the what() method from the
> exception that gets thrown just tells me that there's a
> basic_ios::clear error, and I've verified that errno is 0.

> Does anyone have any suggestions about what I can do?

Not many. This sounds very dependent on the implementation you
are using.

> I thought about retrying, since subsequent writes to that stream
> apparently work. However, my concern is that I don't know the nature
> of the failure. Say I attempted to do a write of 10 bytes from a
> character buffer. Is there any way to tell if it failed and none of
> the bytes got written out, 2 of the bytes, or 9?

No. At the IO stream level, failure is generally considered
fatal; the philosophy is that the stream you were writing is no
longer usable.

> The file system that my ofstream is writing out to is actually
> a ramdisk partition (tmpfs file system).

> I don't mind retrying, if necessary, but I need the output of
> the stream to be correct, which means I need to know from
> where I should be retrying.

> Any ideas?

Only that you'll probably have to access some lower levels (e.g.
by writing your own streambuf). Supposing they support what you
want. (The Posix write function returns the number of bytes
actually written, which is what you seem to need. Most filebuf
will interpret any value other than the number they requested to
write as an error, but you could write something similar which
didn't.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34