interrupting blocked open called on fifo, file-length called on opened fifo

ECL has a segmentation fault when interrupting blocked open call on a FIFO:

Top level in: #<process TOP-LEVEL>.
> (with-open-file (s #P"/home/jack/abc") (file-length s))

Condition of type: INTERACTIVE-INTERRUPT
Console interrupt.

Available restarts:

1. (CONTINUE) CONTINUE
2. (CONTINUE) Ignore signal
3. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (WITH-OPEN-FILE (S #P"/home/jack/abc") (FILE-LENGTH S))] In: #<process TOP-LEVEL>.
>> :r1

Condition of type: SIMPLE-STREAM-ERROR
Error while listening to stream.
C library explanation: Interrupted system call.

Available restarts:

1. (CONTINUE) Ignore signal
2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (WITH-OPEN-FILE (S #P"/home/jack/abc") (FILE-LENGTH S))] In: #<process TOP-LEVEL>.
>> :r1

;;;
;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;


Top level in: #<process TOP-LEVEL>.
> 

Moreover file-length always returns 0 when called on opened FIFO file (regardless the special file state). file-length should return NIL to avoid programmers confusion – we don't know how many characters is available.

Isn't blocking the expected behavior when opening a fifo when the other end isn't open? (Assuming nonblocking mode hasn't been set)

I don't think file-length is important here.

> (open "fifo")
; This blocks.
; Then in a shell I do
;    $ cat >fifo
; and OPEN returns
#<input stream "fifo">
> (file-length *)
0
> (read-line **)
; This blocks.
; In that other shell I write "test" (and hit enter) in cat and this returns
"test"
NIL

And in your example I guess the interrupted system call is just the open system call that was blocking.

Or maybe I misunderstand the problem?

I don't quite remember this issue. Most important problem is that we have some leaking pointer:

;;;
;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

interrupting should gracefully clean after itself.

The second problem is file-length, which returns 0 even if some characters are available in the stream. Since it's impossible to predict how many without reading the file, it should return NIL to mitigate the confusion. This second problem isn't really a bug, rather a feature request.

I think that I had the second problem in mind and when trying to provide a reproducible test-case I have triggered another issue by accident.

changed title from {-file-length called on-} fifo to interrupting blocked open called on fifo, file-length called on opened fifo

I've updated the issue description.

Ah, gotcha. That makes sense then. I guess I focused more on the original description than the output.

changed milestone to %ECL 16.2.0