Smalltalk › Pharo › Pharo Smalltalk Developers

Bug with latest image of Pharo 5

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

kilon.alios

Bug with latest image of Pharo 5

Using latest VM on macos Yosemite
Are you guys aware of this bug ?

Screen Shot 2015-11-27 at 12.19.22.png

This bug strangely happens only for classes with very large amount of methods like the morph class when viewing all protocol and it does not happen immediately, it takes some time to happen and several clicks and navigations through methods. For small classes it does not happen.

I am having this bug for several weeks now with several latest images of Pharo 5.

Is anyone else experiencing this ?

kilon.alios

Re: Bug with latest image of Pharo 5

and this is the stack

UndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ] in ASTCache>>at: in Block: [ aCompiledMethod parseTree... [ self at: key put: aBlock value ] in ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [ self at: key put: aBlock value ] ASTCache(Dictionary)>>at:ifAbsent: ASTCache(Dictionary)>>at:ifAbsentPut: ASTCache>>at: ASTCache class>>at: CompiledMethod>>ast [ :arg1 | arg1 shouldStyle ifTrue: [ self selectedMethod ast acceptVisitor: (arg1 style: self sourceTextModel) ] ] in NautilusUI(AbstractNautilusUI)>>addIconStyle in Block: [ :arg1 | ... Array(SequenceableCollection)>>do: AbstractIconStyler class(Class)>>subclassesDo: NautilusUI(AbstractNautilusUI)>>addIconStyle NautilusUI(AbstractNautilusUI)>>resetIconStyle Nautilus>>package:class:protocol:method: NautilusUI>>forceSelectedMethod: NautilusUI>>selectedMethod: MethodWidget>>selectedMethod: MethodWidget>>selectedMethodIndex: FTPluggableIconListMorphAdaptor>>selectionChangedUpdateIndex: FTPluggableIconListMorphAdaptor>>selectionChanged: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] BlockClosure>>on:do: BlockClosure>>on:fork: AnnouncementSubscription>>deliver: [ subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ subscription deliver: anAnnouncement ] BlockClosure>>ifCurtailed: SubscriptionRegistry>>deliver:to:startingAt:

On Fri, Nov 27, 2015 at 12:26 PM Dimitris Chloupis <[hidden email]> wrote:

Using latest VM on macos Yosemite
Are you guys aware of this bug ?

This bug strangely happens only for classes with very large amount of methods like the morph class when viewing all protocol and it does not happen immediately, it takes some time to happen and several clicks and navigations through methods. For small classes it does not happen.

I am having this bug for several weeks now with several latest images of Pharo 5.

Is anyone else experiencing this ?

Thierry Goubier

Re: Bug with latest image of Pharo 5

A problem with the ast cache ending out of space?

Thierry

2015-11-27 11:30 GMT+01:00 Dimitris Chloupis <[hidden email]>:

and this is the stack

UndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysisIn: [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ] in ASTCache>>at: in Block: [ aCompiledMethod parseTree... [ self at: key put: aBlock value ] in ASTCache(Dictionary)>>at:ifAbsentPut: in Block: [ self at: key put: aBlock value ] ASTCache(Dictionary)>>at:ifAbsent: ASTCache(Dictionary)>>at:ifAbsentPut: ASTCache>>at: ASTCache class>>at: CompiledMethod>>ast [ :arg1 | arg1 shouldStyle ifTrue: [ self selectedMethod ast acceptVisitor: (arg1 style: self sourceTextModel) ] ] in NautilusUI(AbstractNautilusUI)>>addIconStyle in Block: [ :arg1 | ... Array(SequenceableCollection)>>do: AbstractIconStyler class(Class)>>subclassesDo: NautilusUI(AbstractNautilusUI)>>addIconStyle NautilusUI(AbstractNautilusUI)>>resetIconStyle Nautilus>>package:class:protocol:method: NautilusUI>>forceSelectedMethod: NautilusUI>>selectedMethod: MethodWidget>>selectedMethod: MethodWidget>>selectedMethodIndex: FTPluggableIconListMorphAdaptor>>selectionChangedUpdateIndex: FTPluggableIconListMorphAdaptor>>selectionChanged: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] BlockClosure>>on:do: BlockClosure>>on:fork: AnnouncementSubscription>>deliver: [ subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ subscription deliver: anAnnouncement ] BlockClosure>>ifCurtailed: SubscriptionRegistry>>deliver:to:startingAt:

On Fri, Nov 27, 2015 at 12:26 PM Dimitris Chloupis <[hidden email]> wrote:
Using latest VM on macos Yosemite
Are you guys aware of this bug ?

This bug strangely happens only for classes with very large amount of methods like the morph class when viewing all protocol and it does not happen immediately, it takes some time to happen and several clicks and navigations through methods. For small classes it does not happen.

I am having this bug for several weeks now with several latest images of Pharo 5.

Is anyone else experiencing this ?

Marcus Denker-4

Re: Bug with latest image of Pharo 5

In reply to this post by kilon.alios

> On 27 Nov 2015, at 07:26, Dimitris Chloupis <[hidden email]> wrote:
>
> Using latest VM on macos Yosemite
> Are you guys aware of this bug ?
>

No, I have not yet seen it. It would nice to have a reproducible case (or an image save in
this state).

Marcus

Nicolai Hess-3-2

Re: Bug with latest image of Pharo 5

In reply to this post by kilon.alios

Wow what an awful bug, it turned you whole screen in ugly blue!
:)

No, never seen this. If it happened with several recent 5.0 images, can you name the first

and last it occurred for you.

kilon.alios

Re: Bug with latest image of Pharo 5

In reply to this post by Marcus Denker-4

To reproduce it these are the steps

1) Open Nautilus to Morph class

2) select all protocol

3) start clicking or use the down arrow to rapidly move from method to method source

4) after 5-20 seconds of clicking the error appears and the method column turns red box of doom.

The error is random and does not happen with specific methods, but rather it happens with large classes, small ones seem immune so far to it.

I have zipped my entire folder you can get it from here

https://www.dropbox.com/s/nhm3fwmq0n2t8fy/Ephestos.zip?dl=0

The problem seem also not to happen on my ubuntu with exactly same setup for the image.

This is how i get the image and the VM

wget -O- get.pharo.org/alpha+vmLatest | bash

On Fri, Nov 27, 2015 at 12:53 PM Marcus Denker <[hidden email]> wrote:

> On 27 Nov 2015, at 07:26, Dimitris Chloupis <[hidden email]> wrote:
>
> Using latest VM on macos Yosemite
> Are you guys aware of this bug ?
>

No, I have not yet seen it. It would nice to have a reproducible case (or an image save in
this state).

Marcus

demarey

Re: Bug with latest image of Pharo 5

In reply to this post by Nicolai Hess-3-2

Le 27 nov. 2015 à 12:28, Nicolai Hess a écrit :

Wow what an awful bug, it turned you whole screen in ugly blue!
:)

like a windows system error

How to fix blue screen error in windows???

smime.p7s (5K) Download Attachment

kilon.alios

Re: Bug with latest image of Pharo 5

In reply to this post by Nicolai Hess-3-2

Wow what an awful bug, it turned you whole screen in ugly blue!
:)

https://www.youtube.com/watch?v=F2AitTPI5U0

What I can say , some of use dont see the world black and white :)

No, never seen this. If it happened with several recent 5.0 images, can you name the first
and last it occurred for you.

I get latest pharo 5 images every day via

wget -O- get.pharo.org/alpha+vmLatest | bash

and it has been happening 1-2 weeks now. But I was patient dude since I assumed it was one of the refactorings people have been doing with pharo 5.

kilon.alios

Re: Bug with latest image of Pharo 5

In reply to this post by demarey

well the blue theme I am using is called Nireas, made by me. Its inspired from best computer ever, Amiga 500

^ that's Amiga's OS

On Fri, Nov 27, 2015 at 2:11 PM Christophe Demarey <[hidden email]> wrote:

Le 27 nov. 2015 à 12:28, Nicolai Hess a écrit :

Wow what an awful bug, it turned you whole screen in ugly blue!
:)

like a windows system error

kilon.alios

Re: Bug with latest image of Pharo 5

I found how to easily reproduce it every time

1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser

2) Boom MNU

looking at

[..] inAstCache

at: aCompiledMethod
^ self at: aCompiledMethod ifAbsentPut:
[ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ]

The problem here is even though aCompiledMethod returns the correct method in this case

Morph>>#addMiscExtrasTo:

the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case

anyone have a clue why its nil ?

if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method.

Deadends everywhere .

On Fri, Nov 27, 2015 at 2:17 PM Dimitris Chloupis <[hidden email]> wrote:

well the blue theme I am using is called Nireas, made by me. Its inspired from best computer ever, Amiga 500

^ that's Amiga's OS

On Fri, Nov 27, 2015 at 2:11 PM Christophe Demarey <[hidden email]> wrote:

Le 27 nov. 2015 à 12:28, Nicolai Hess a écrit :

Wow what an awful bug, it turned you whole screen in ugly blue!
:)

like a windows system error

Marcus Denker-4

Re: Bug with latest image of Pharo 5

> On 27 Nov 2015, at 12:15, Dimitris Chloupis <[hidden email]> wrote:
>
> I found how to easily reproduce it every time
>
> 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser
> 2) Boom MNU
>
> looking at
> [..] inAstCache
> at: aCompiledMethod
> ^ self at: aCompiledMethod ifAbsentPut:
> [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ]
>
> The problem here is even though aCompiledMethod returns the correct method in this case
>
> Morph>>#addMiscExtrasTo:
>
> the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case
>
>
> anyone have a clue why its nil ?
>
> if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method.
>

I think it happens because the text it reads from the .changes or .sources is somehow corrupted.

We should not return #nil but fall back on the decompiler in #parseTree…

Marcus

kilon.alios

Re: Bug with latest image of Pharo 5

Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom.

There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image.

But no complains , it looks like now the problem is gone.

On Fri, Nov 27, 2015 at 5:26 PM Marcus Denker <[hidden email]> wrote:

> On 27 Nov 2015, at 12:15, Dimitris Chloupis <[hidden email]> wrote:
>
> I found how to easily reproduce it every time
>
> 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser
> 2) Boom MNU
>
> looking at
> [..] inAstCache
> at: aCompiledMethod
> ^ self at: aCompiledMethod ifAbsentPut:
> [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ]
>
> The problem here is even though aCompiledMethod returns the correct method in this case
>
> Morph>>#addMiscExtrasTo:
>
> the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case
>
>
> anyone have a clue why its nil ?
>
> if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method.
>

I think it happens because the text it reads from the .changes or .sources is somehow corrupted.

We should not return #nil but fall back on the decompiler in #parseTree…

Marcus

Marcus Denker-4

Re: Bug with latest image of Pharo 5

> On 27 Nov 2015, at 13:32, Dimitris Chloupis <[hidden email]> wrote:
>
> Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom.
>
> There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image.
>
> But no complains , it looks like now the problem is gone.
>

The .changes does not only have the changes that you did, but in addition all changes that we did to Pharo since the release of Pharo4…

The whole mechanism is not very good… we really should replace it. The good news is that we are working on the first step
already: Epicea will be used for recording changes, so after that we re free to simplify source storage as it will now overlap anymore
with change history recording.

Be careful with an image where you delete the .changes: all methods that point to that file will be decompiled… losing comments and much more.

The best thing is to re-create an image from the release (loading your code).

Marcus

kilon.alios

Re: Bug with latest image of Pharo 5

yes as always you are correct I lost the names of all my temporary variables but I got that fixed by reimporting the filetree repository.

Thank you for your efforts they never go unnoticed.

By the way this is a fresh image that does this, I use a startup script to load all my libraries. Maybe one of those libs does something funky to the changes file. Epicea looks interesting.

The one thing that makes me wonder is how needed the image file format really is. I get it that is there to store the complete live enviroment but even in that case it can still be broken to individual files each with a specific role, some binary and some text. Afterall there is no reason why state cannot be stored even in text files. In any case I know you guys have many good ideas to improve the situation and I am sure with time you will.

On Fri, Nov 27, 2015 at 7:37 PM Marcus Denker <[hidden email]> wrote:

> On 27 Nov 2015, at 13:32, Dimitris Chloupis <[hidden email]> wrote:
>
> Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom.
>
> There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image.
>
> But no complains , it looks like now the problem is gone.
>

The .changes does not only have the changes that you did, but in addition all changes that we did to Pharo since the release of Pharo4…

The whole mechanism is not very good… we really should replace it. The good news is that we are working on the first step
already: Epicea will be used for recording changes, so after that we re free to simplify source storage as it will now overlap anymore
with change history recording.

Be careful with an image where you delete the .changes: all methods that point to that file will be decompiled… losing comments and much more.

The best thing is to re-create an image from the release (loading your code).

Marcus