[Openmcl-devel] Bug when writing to broken pipe?

[Gary Byers]

On 12/04/2014 05:00:23 PM, Ron Garret wrote:
> 
> On Dec 4, 2014, at 1:54 PM, Gary Byers <gb at clozure.com> wrote:
> 
> > On 12/03/2014 02:55:20 PM, Ron Garret wrote:
> >> On Dec 3, 2014, at 12:35 PM, Gary Byers <gb at clozure.com> wrote:
> >> > i haven't looked at this or even thought about it much yet, but  
> my first reaction - which could be misguided - is to suggest running  
> the saved image with the --batch option.  That should cause any  
> unhandled error to abruptly terminate the application and may (I  
> don't remember the details) cause *TERMINAL-IO* to be initialized  
> differently, and I expect that the death spiral you're getting has to  
> do with the fact that the initial thread is trying to FORCE-OUTPUT on  
> the output side of *TERMINAL-IO*, which is ordinarily the same stream  
> as *STANDARD-OUTPUT* …
> >> It has nothing to do with any of that.  It’s simply a bug: the -b  
> flag doesn’t work as advertised when entering a break loop:
> >
> > I still haven't looked at this at all carefully, but your example  
> sure looked to me like the -b option was working as advertised  
> (though the output was truncated at the end and the advertisement  
> should be updated to note that an attempt is made to print a  
> backtrace before exiting
> 
> That is not a negligible difference.  When stdout is on a broken  
> pipe, any attempt by CCL to output anything to stdout on an error  
> will result in an infinite cascade of “broken pipe” errors, which is  
> exactly what Andreas was reporting.
> 
> rg
> 
> 
> 

The cascade of broken pipe errors seems to have to do with the fact  
that CCL ordinarily calls FORCE-OUTPUT ~3 times a second on  
*TERMINAL-IO*, and the output side of *TERMINAL-IO* and  
*STANDARD-OUTPUT* are (usually) either the same stream or backed by the  
same Unix file descriptor.  When -b/--batch is specified and CCL and  
can access some sort of (real or pseudo) terminal device, *TERMINAL-IO*  
the file descriptors "underneath" *TERMINAL-IO* are connected to that  
tty device and  a broken pipe on fd 1 is not likely to affect attempts  
to write to (or periodically FORCE-OUTPUT to) *TERMINAL-IO* (directly  
or via any other stream which is a synonym stream to *TERMINAL-IO*.)

I don't know if the -b option is the best solution (or even a good or  
correct one) and I still need to actually read the other messages in  
this thread, but I don't think it's likely that it's as unrelated to  
the problem as you say.  (Since someone has seemingly Said Something  
Wrong On The Internet, I naturally need to obsess about that before  
doing anything that might be more useful.)