PR# 19155 Resizing terminal window causes io.read_line to raise runtime I/O error

Problem Report Summary
Submitter: prestoat2000
Category: Runtime
Priority: Medium
Date: 2015/11/10
Class: Bug
Severity: Serious
Number: 19155
Release: 15.08.97862
Confidential: No
Status: Analyzed
Environment: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Synopsis: Resizing terminal window causes io.read_line to raise runtime I/O error

I have a program that prompts for input via a call to io.read_line.
If I resize the terminal window while that routine is waiting for input,
I get an exception.  Trace is:

CONSOLE             console_readline       FILE: unable to read current line.:
<000000000A86FEF8>                         Runtime I/O error.            Fail

So far, I can only reproduce this issue after the program logs into our
Oracle database - not sure why.

I printed the value of errno in a rescue clause after the failure and it
is 4 (EINTR).  So I think eif_file_gs (and a whole bunch of other routines in
file.c) needs to do something similar to EIF_REPEAT_INTERRUPTED_CALL,
which is that if ferror indicates an error on the stream, then errno must
be checked and if it is EINTR, then the call needs to be retried.
EIF_REPEAT_INTERRUPTED_CALL cannot be used because it checks for a return
value of -1, but the C library functions don't work that way.

I supposed I could wrap all calls to io.read_line and similar read functions
and check for errno myself, repeating the call if errno is EINTR, but that 
would be rather inconvenient.

Hoping for a fix someday.
To Reproduce
So far, I have only been able to reproduce the problem when I call io.read_line
after logging into our Oracle database.

Problem Report Interactions
From:prestoat2000    Date:2015/11/11    Download   
Yes, I think it is likely that the Oracle library is setting some signal
handlers.  That would explain the observed behavior.  But the Eiffel runtime
should still be able to retry when ferror returns True but errno = EINTR.

From:manus_eiffel    Date:2015/11/11    Status: Analyzed    Download   
Could it be that the C code of the Oracle database binding is resetting some of our signal handling? Especially the SIGWINCH signal? By default we ignore it, but if they enable it, then we would catch that signal.