Given the nature of your problem, it probably wouldn't make
sense for you to send a test case.
The I/O errors may be real. StdOFStream::write() explicitly
sets errno to 0 (no error) before writing to the output file
and checking for errors. If the error check ends up throwing
an Iex::EioExc exception, errno must have been set to 5 (EIO)
during the write operation.
To make sure errno isn't just being overwritten by spurious
memory references, you may want to check the return values of
all write() and lseek() system calls.
Aside from a possible bug in the IlmImf library, I can think
of at least two reasons reasons why only OpenEXR seems to be
affected by I/O errors: The errors might occur only for
certain I/O patterns. (I've been told that a while ago we
had some faulty piece of hardware here at ILM that caused bit
errors only on one particular type of file.) Also, some file
I/O libraries may not check the error status of every system
call; this could mask occasional I/O errors.
Florian
Ken McGaugh wrote:
This is using version 1.2.1. The shake translater is custom, while
the prman one is ILM's published display driver (with minor changes).
We are catching all exceptions, and in this case it is an Iex::EioExc
exception initially caught by Imf::OutputFile::writePixels(). Ultimately
I think it is being thrown by Imf::StdOFStream::write(), although it may
be in one of the other routines which does a seek.
Would modifying the ofstream's buffer settings to alleviate this kind
of problem? Or would doing
ios::sync_with_stdio(false);
help at all?
Thanks.
--Ken
Piotr Stanczyk wrote:
Are you using a custom node and catching the exceptions? If so, do
you know what they are?
We've had some intermittent seek problems here with both our own code
and the publicly posted one when rendering heavy scenes on the farm.
What version are you using?
Piotr
On 2 Aug 2004, at 12:35, Ken McGaugh wrote:
Hello, our OpenEXR renders both from shake and prman have been
experiencing "Input/output" errors. I tracked it down to an errno
error, implying that it is a hardware and/or network problem. But
renders to other file formats don't suffer from this. Has anybody
else noticed this? Any ideas on how to work around them?
Thanks.
--Ken
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel
________________________________________________
Dr. Piotr Stanczyk
R&D
Digital Film
The Moving Picture Company - http://www.moving-picture.com
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel