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
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, 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
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, 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
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
And 30 has the exact same problem of course (just checked). On 16.09.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
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
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 <sven@stfx.eu> 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 <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
On 16 Sep 2014, at 09:24, Max Leske <maxleske@gmail.com> 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 <sven@stfx.eu> 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 <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
On 16.09.2014, at 09:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Sep 2014, at 09:24, Max Leske <maxleske@gmail.com> 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 <sven@stfx.eu> 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 <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
participants (4)
-
jdelgado＠lsi.upc.edu -
Jordi Delgado
-
Max Leske -
Sven Van Caekenberghe