Transcript had a 1.25GB WriteStream - maybe a bug with clearing the Transcript?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Transcript had a 1.25GB WriteStream - maybe a bug with clearing the Transcript?

Paul DeBruicker
Hi -

On Pharo 7.1 64bit mac mojave.  My images grew to 1.4GB, so I ran

ImageCleaner cleanUpForRelease.
Smalltalk cleanUp.
Smalltalk reportCPUAndRAM.

to begin to track down why & I found that I had 1.3 GB of ByteStrings.

(ByteString allInstances select:[:ea | ea size >1000]) sorted:[:a :c | a  size > c size]

gave me a list of 1174 strings.


self collect:[:ea | ea size]

showed me that the first one in the list is 1245704483 characters long.  And the next biggest one is 520714 (that one is the highchartsJS library stored in a MCMethodDefinition)

John Brant's ReferenceFinder & the "Open pointers to" shows that the very long String is the collection of the Transcript's stream.

The only thing that got rid of the big string  was running

Transcript initialize.
10 timesRepeat:[Smalltalk garbageCollect].

Then saving/closing/reopening the image.  

I had always assumed that when you delete the contents of the Transcript, by selecting everything in it and deleting it ,it was all deleted.  Or when running

Transcript clear

Or one of the "clean up" methods like those above.  

Anyway. It seems like the stream should clear more often than it does (looks like it may never empty itself?  I don't think there is code in the image that does that though.

WriteStream>>#reset & WriteStream>>#close do not empty the #collection or #stepContents inst vars.  And it doesn't look like there is a method to empty/re-initailze those inst vars defined in the Stream hierarchy in 7.1 or 8.0.

I made an issue