Well, since SequenceableCollection overwrites #do: breaking its superclass' contract, it should also overwrite #size as subclassResponsibility - at least. That would break the loop, no ? The discussion about catching infinite recursion loops is old and comes up every couple of weeks. It should be fixed, it can be fixed IMHO, but it is a VM thing. On 16 Sep 2014, at 08:39, Max Leske <maxleske@gmail.com> wrote:
So first: as Sven said Sequenceable collection is abstract. Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported.
I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent.
SequenceableCollection>>do: aBlock "Refer to the comment in Collection|do:.â 1 to: self size do: [:index | aBlock value: (self at: index)]
Collection>>size size "Answer how many elements the receiver contains.â
| tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally
As you can see, calling either method will produce an infinite loop which eventually crashes the VM.
I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-o...
Cheers, Max
On 15.09.2014, at 23:12, jdelgado@lsi.upc.edu wrote:
Hi,
A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check.
The thing is simple:
1) Create a class with accessors for f.
SequenceableCollection subclass: #Foo instanceVariableNames: 'f' classVariableNames: '' category: 'Varios'
2) Foo class >> new: d ^self new f: (Array new: d*d)
3) Go to Workspace and inspect the following code
| m | m := Foo new: 2
And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks.
So, is this a known issue?
Bests,
Jordi