From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Sat, 1 Oct 2016 12:33:00 +0100 Subject: SIGPIPE from syntax highlighting filter if highlight is not available In-Reply-To: References: Message-ID: <20161001113300.GQ1673@john.keeping.me.uk> On Thu, Sep 29, 2016 at 04:38:41PM +0200, Vadim Zeitlin wrote: > As this is the first time I'm posting here, let me start by thanking you > for developing cgit! I'm using it since quite some time under Debian > (currently Jessie) and it works very well but recently I've mistakenly > removed highlight package because I thought it was redundant with other > similar tools and completely forgot that cgit depended on it. > > Since then, viewing any files in cgit didn't work, which was probably only > to be expected, but viewing sufficiently large files resulted in 500 server > error due to, after debugging, SIGPIPE received but not handled by cgit > when reading from the filter subprocess. > > I'm not sure what exactly should be done here: maybe nothing, and people > should be just more careful with uninstalling dependencies. But I think > ideally cgit should give an error indicating that filter execution failed > and I'd at least expect it not to just die without any further information. If we ignore SIGPIPE we should just hit the die_errno() in html.c::html_raw() which will say "write error on html output". That's not really as useful as it could be, since that code doesn't care whether or not it's writing via a filter. I'm not sure if we want to start keeping track of whether we're writing through a filter, but some form of error message rather than a silent failure does seem like an improvment. I think we just need to ignore SIGPIPE to make that happen.