Backporting just this fix to a special Stapler release for 2.70.x LTS is an option, but first I would like to understand this issue better.
First, the reproduction cases: they all claim to involve broken Groovy scripts which accidentally call Run.getLogText and thus use LargeText.GzipAwareSession.isGzipStream. But would the same thing not happen when you just access a build log any other way, say using a /jobs///console link?
Second, the cause. isGzipStream did close its file handle already. As JDK-8080225 notes (cf. JENKINS-42934), this is not an issue of a file handle leak, just of an unnecessary burden on the GC system in the JRE. But the reported symptom is of file handle leaks. AFAICT the only code in LargeText (or AnnotatedLargeText) which could cause a leak if used improperly is the Session which must have its close method called. Since the session is private, and writeLogTo does so itself (albeit without using a finally block as it should), that leaves readAll, whose caller must close the Reader. But then who is calling readAll? Just calling getLogText does not.
Until the mechanism of the bug, and the effectiveness of the fix, is explained, I would not want to risk a backport.
Reproduction test:
Run freestyle job with system groovy step:
Now the above script is not a correct script, but use of Groovy's magic "proprerties" property exposes the file leak when instantiating the Run.getLogText() "property", you get file handle leaks like:
The differentiator from
JENKINS-45057is that these are READ locks not WRITE locks.