Bug with latest image of Pharo 5
Using latest VM on macos Yosemite Are you guys aware of this bug ? [image: 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 ?
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 <kilon.alios@gmail.com> wrote:
Using latest VM on macos Yosemite Are you guys aware of this bug ?
[image: 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 ?
A problem with the ast cache ending out of space? Thierry 2015-11-27 11:30 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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 <kilon.alios@gmail.com> wrote:
Using latest VM on macos Yosemite Are you guys aware of this bug ?
[image: 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 ?
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 <marcus.denker@inria.fr> wrote:
On 27 Nov 2015, at 07:26, Dimitris Chloupis <kilon.alios@gmail.com> 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
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.
well the blue theme I am using is called Nireas, made by me. Its inspired from best computer ever, Amiga 500 [image: amigaos_1-0b3_workbench_2012.png] ^ that's Amiga's OS On Fri, Nov 27, 2015 at 2:11 PM Christophe Demarey < Christophe.Demarey@inria.fr> 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
[image: How to fix blue screen error in windows???]
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 <kilon.alios@gmail.com> wrote:
well the blue theme I am using is called Nireas, made by me. Its inspired from best computer ever, Amiga 500
[image: amigaos_1-0b3_workbench_2012.png]
^ that's Amiga's OS
On Fri, Nov 27, 2015 at 2:11 PM Christophe Demarey < Christophe.Demarey@inria.fr> 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
[image: How to fix blue screen error in windows???]
On 27 Nov 2015, at 12:15, Dimitris Chloupis <kilon.alios@gmail.com> 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 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 <marcus.denker@inria.fr> wrote:
On 27 Nov 2015, at 12:15, Dimitris Chloupis <kilon.alios@gmail.com> 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
On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios@gmail.com> 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
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 <marcus.denker@inria.fr> wrote:
On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios@gmail.com> 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
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.
participants (5)
-
Christophe Demarey -
Dimitris Chloupis -
Marcus Denker -
Nicolai Hess -
Thierry Goubier