[BUG] .changes file position overflowing at 16M size

Dan Ingalls Dan.Ingalls at disney.com
Sun Apr 16 15:56:42 UTC 2000


Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote...

>Michael Rueger wrote:
>
>> Yeah, we were bitten by that too :-(
>> Workarounds:
>> - when testing stuff producing large amounts of changes consider rolling
>> back to the original changes file every time before you start the image.
>> Don't forget to file out the changes you want to keep before you do
>> that.
>> - run a condense changes in between (at least in the test image)
>> - build a test image with condensed sources, so you start with an empty
>> changes file. That gives you plenty of room for producing changes
>
>Thanks Michael,
>
>Your tips do the work, but I think this also warrants some general remedy.
>16M is a little too close for comfort, since for instance now the changes
>file comes at 9.4M out of the box. Try a goodie from the list now and then,
>and you'll be there soon.
>
>One fix would be to go to say six (or more) instead of four bytes in those
>methods for which four are not enough. I guess there must be a free value
>for the last trailer byte to do such a thing. However I don't know enough
>about the method format et al. to do such a thing properly. Can someone
>educate me about that trailer byte etc.?

Henrik -

This would not be at all hard to "fix" -- I have thought of doing it several times.  Take a look at the following method:

<CompiledMethod>fileIndex
	"Answer the index of the sources file on which this method is stored, as follows:
		1:	.sources file
		2:	.changes file
		3 and 4 are also available for future extension of source code management"
	self last < 252 ifTrue: [^ 0  "no source"].
	^ self last - 251

So Squeak as it stands anticipates the possibility of up to four changes files.  I set it up this way decades ago because I didn't know how things would go, and I sort of thought it might be useful for packages.  I recently thought some more about the package situation and realized that a package can use fileIndex 1 without any ambiguity if it has its own source file anyway.

With this realization, I think it would be pefectly reasonable to change the defs of fileIndex and filePosition to commit to two source files (a convention that has stood the test of time pretty well) and double the size limit of each.

A problem in 2.8 is that the source version back-links rely on the current mod-16M encoding.  I think, however that it would be easy to do a compatibility hack in just two places to accomodate this, and then it can be cleared up when we go to 3.0 (ie when we write a new sources file).  We have talked of moving to Tim's NCM format at that point also, which lends itself naturally to a different encoding anyway.

I have most of the code for a fix outlined already, so I'll try it out and then send it along if it doesn't break (you can be my alpha tester before I put it out).  I'll also include a warning that will start appearing when you come within 100k of the new 32M limit.

	- Dan






More information about the Squeak-dev mailing list