On Tue, Feb 09, 2021 at 10:02:47PM +0100, Barath Aron wrote: > On 2/9/21 9:55 PM, Gavin Smith wrote: > > On Tue, Feb 09, 2021 at 09:10:28PM +0100, Barath Aron wrote: > > > The code path I wrote is the trace of the program, I didn't made it up. It > > > first opened a regular, non-compressed file with fopen() [this was in line > > > 700], then it would freopen()ed [line 882, but it won't make any > > > difference], then closed the fopen()ed file with pclose() [line 939]. And > > > per-definition, you can't pclose() a FILE opened with fopen(). It is > > > undefined behavior, libc is "allowed" to wait for something which will not > > > happen. > > > POSIX spec says: "If the argument stream to pclose() is not a pointer to a > > > stream created by popen(), the result of pclose() is undefined." > > > So, on Linux and on some other OSs this case works by mistake, but it is > > > not > > > required. > > Yes, it is clearly wrong in this case. It's just a question now of > > understanding the changes in the two earlier commits and making > > sure that we don't break anything that those commits were supposed to > > fix. One way to fix it would be reinstate the is_pipe argument and > > only call pclose if it's a pipe. > > Sounds good! The is_pipe argument would definitely solve the issue. My > modification was really just a "make this thing work ASAP, better a resource > leak than a hangup, until it is really fixed".
I've attempted a fix in commit c3cd8f03e. I'm always nervous to make changes like this.
