Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
-
Running on Solaris 10 (sparc). Tomcat 6.0.29. Jenkins 401 and 404. This was not an issue in Hudson 380. JVM is set to 1.5GB on one system and 2GB on another.
Description
Run a build that generates a large console output. Say around 10MB or more. View the console log for the build. It should work just fine. Add the timestamper and run the build again (version 0.6). View the console log. Select to view full log. This frequently crashes Jenkins/Tomcat. Sometimes I actually get the whole log. This has occurred after a restart as well as after it has been running for a bit. I don't see the issue when view logs without the timestamper enabled (at least not yet).
I have a hunch. timestamper uses an exntesion point called console annotation which stores a small compressed gzip stream of data into the log file. It uses a lot of those, because each timestamp it's adding, I believe, is a new annotation.
If there's a race condition in the write operations, it could corrupt the gzip encoded stream, and I wonder if it can happen just in the right away that breaks the decompressor like this.
If my hypothesis is correct, trying to look at the problematic build log will consistently reproduce the problem (as opposed to "sometimes I can see build #15 but some times it crashes when looking at the same build #15.)
If this fits the issue you are seeing, please attach your console output (or send it personally to me if it's sensitive), and that'd greatly simplify our efforts to fix the issue.