Strange behavior in Pharo 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behavior in Pharo 3.0

jdelgado

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

Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Sven Van Caekenberghe-2
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

jdelgado
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
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Max Leske
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.


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



Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Max Leske
And 30 has the exact same problem of course (just checked).


On 16.09.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.


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




Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Sven Van Caekenberghe-2
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
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Max Leske
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
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Sven Van Caekenberghe-2

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
>>>>
>>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior in Pharo 3.0

Max Leske

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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>