[Vm-dev] Help/advice tracking down a squeak-vm regression

[Igor Stasenko]

Here the method in question:

adjustAllOopsBy: bytesToShift
	"Adjust all oop references by the given number of bytes. This
	is done just after reading in an image when the new base
	address of the object heap is different from the base address
	in the image."
	"di 11/18/2000 - return number of objects found"

	| oop totalObjects |
	<inline: false>
	bytesToShift = 0 ifTrue: [^300000].
	"this is probably an improvement over the previous answer of
	nil, but maybe we should do the obejct counting loop and
	simply guard the adjustFieldsAndClass... with a bytesToShift
	= 0 ifFalse: ?"
	totalObjects := 0.
	oop := self firstObject.
	[self oop: oop isLessThan: endOfMemory]
		whileTrue:
			[(self isFreeObject: oop)
				ifFalse:
					[totalObjects := totalObjects + 1.
					 self adjustFieldsAndClassOf: oop by: bytesToShift].
			 oop := self objectAfter: oop].
	^totalObjects


i really doubt that it loops there forever.
if it does, then i think image file is corrupt, because the algorithm
is quite deterministic
and oop is incrementing at every iteration, so there is no way how it
can run infinitely.

P.S. and sure thing, slang part is version controlled.
See: source.squeak.org/VMMaker

On 5 May 2012 18:53, Alex Bradbury <asb at asbradbury.org> wrote:
>
> Hi all,
>
> As some of you may know, MIT Scratch does not work on the latest
> squeak-vm (4.4.7-2353). This is unfortunate, because that's the
> version of squeak-vm packaged in Debian wheezy and thanks to the
> recent GPLv2 relicensing of Scratch this incompatibility is the only
> thing preventing Scratch from getting in to Debian's package archive
> before the 'freeze' for the next version version (wheezy).
>
> Miriam Ruiz and others have done some debugging at
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471927>. The
> symptoms are that when opening the Scratch image, you just get a black
> window and 100% CPU usage. See Miriam's posts for straces and the
> section of code that loops forever. In a situation like this, I'd
> normally just do a binary search through the changes between the
> working 4.0.3 and broken 4.4.7 using git bisect. However, given that
> the VM code is automatically generated by VMM (is the Slang source
> even version controlled?) I can't see an easy way to do that.
>
> I'd really appreciate any help anyone can offer in debugging this issue,
>
> Many thanks,
>
> Alex



-- 
Best regards,
Igor Stasenko.