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 2) Foo class >> new: d 3) Go to Workspace and inspect the following code | m | 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 |
SequenceableCollection is abstract.
Collection methods select: #isSubclassResponsibility. => {Collection>>#add:. Collection>>#do:. Collection>>#remove:ifAbsent:} The inspector probably fails because it cannot enumerate the collection. But I haven't actually tried your code. On 15 Sep 2014, at 23:12, [hidden email] 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 > > |
Yes, that would be ok. But the problem is not the Inspector failing, the problem is that Pharo crashes, and that should not happen.
Bests, Jordi > SequenceableCollection is abstract. > > Collection methods select: #isSubclassResponsibility. > > => {Collection>>#add:. Collection>>#do:. Collection>>#remove:ifAbsent:} > > The inspector probably fails because it cannot enumerate the collection. > > But I haven't actually tried your code. > > On 15 Sep 2014, at 23:12, [hidden email] 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 > > > > > > |
In reply to this post by jdelgado
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, [hidden email] wrote:
|
And 30 has the exact same problem of course (just checked). On 16.09.2014, at 08:39, Max Leske <[hidden email]> wrote:
|
In reply to this post by Max Leske
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 <[hidden email]> 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, [hidden email] 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 >> >> > |
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 <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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 >>> >>> >> > > |
On 16 Sep 2014, at 09:24, Max Leske <[hidden email]> wrote: > Slice in inbox. > > Required reimplementing #size in Stack and LinkedList. Argh, that is a bit ugly. Stack>>#size is not needed as it inherits from LinkedList, right ? Otherwise: checked and all Collection tests ran OK. > 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 <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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 >>>> >>>> >>> >> >> > > |
On 16.09.2014, at 09:50, Sven Van Caekenberghe <[hidden email]> wrote: > > On 16 Sep 2014, at 09:24, Max Leske <[hidden email]> wrote: > >> Slice in inbox. >> >> Required reimplementing #size in Stack and LinkedList. > > Argh, that is a bit ugly. > > Stack>>#size is not needed as it inherits from LinkedList, right ? Ouch. Missed that. Thanks for checking! Fixed in new slice. Name: SLICE-Issue-14022-Infinite-loop-in-simple-subclasses-of-SequenceableCollection-MaxLeske.2 Author: MaxLeske Time: 16 September 2014, 10:11:57.66599 am UUID: d8315688-7ecb-4222-8216-fddbfddbb79e Ancestors: Dependencies: Collections-Abstract-MaxLeske.266, Collections-Sequenceable-MaxLeske.174 Break potential infinite loop in subclasses of SequenceableCollection by making #size a subclass responsibility > > Otherwise: checked and all Collection tests ran OK. > >> 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 <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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 >>>>> >>>>> >>>> >>> >>> >> >> > > |
Free forum by Nabble | Edit this page |