Intermittent Failure on Serial Port (Trace Result)

[Serge Orlov]

H J van Rooyen wrote:

> Note that the point of failure is not the same place in the python file, but it
> is according to the traceback, again at a flush call...

Yes, traceback is bogus. Maybe the error is raised during garbage
collection, although the strace you've got doesn't show that. The main
reason of the failure seems to be a workaround in python's function
new_buffersize, it doesn't clear errno after lseek and then this errno
pops up somewhere else. There are two places I can clearly see that
don't clear errno: file_dealloc and get_line. Obviously this stuff
needs to be fixed, so you'd better file a bug report. I'm not sure how
to work around this bug in the meantime, since it is still not clear
where this error is coming from. Try to pin point it. For example, if
your code relies on garbage collection to call file.close, try to close
all files in your program explicitly. It seems like a good idea anyway,
since your program is long running, errors during close are not that
significant. Instead of standard close I'd call something like this:

def soft_close(f):
    try:
        f.close()
    except IOError, e:
        print >>stderr, "Hmm, close of file failed. Error was: %s" %
e.errno

> The "close failed" is explicable - it seems to happen during closedown, with the
> port already broken..,

It is not clear who calls lseek right before close. lseek is called by
new_buffersize that is called by file.read. But who calls file.read
during closedown?