Slice in inbox. Required reimplementing #size in Stack and LinkedList.
Name: SLICE-Issue-14022-Infinite-loop-in-simple-subclasses-of-SequenceableCollection-MaxLeske.1 Author: MaxLeske Time: 16 September 2014, 9:23:03.047607 am UUID: a911f5cc-bc3e-4579-bbf4-ad6f61d1199c Ancestors: Dependencies: Collections-Abstract-MaxLeske.265, Collections-Sequenceable-MaxLeske.173, Collections-Stack-MaxLeske.8 Break potential infinite loop in subclasses of SequenceableCollection by making #size a subclass responsibility On 16.09.2014, at 09:10, Sven Van Caekenberghe <[email protected]> wrote: > 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 <[email protected]> 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-of-SequenceableCollection >> >> Cheers, >> Max >> >> On 15.09.2014, at 23:12, [email protected] 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 >>> >>> >> > >
