Image not startable after save

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

Image not startable after save

Jakob Reschke
Hi all,

I just updated my Squeak trunk image. After saving, I cannot reload it:

---------------------------
Squeak!
---------------------------
Aborting!!!!
Color depth 0 not supported
---------------------------
OK
---------------------------

Then it prints the stack trace and exits.

I restored a backup from yesterday and reloaded my own changes. An
image saved from that is still functional. After updating Squeak
again, I see the same error as above, so it is reproducible.

But I cannot invoke the error with a fresh image... so it must be
something with my image after all. Any ideas or suggestions? Does
anyone else experience issues after an update?

Kind regards,
Jakob

Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
This is from the image before the update, the VM is the same (should
be the 5.3 release VM if I remember correctly):

Image
-----
C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
Squeak6.0alpha
latest update: #19634
Current Change Set: Git unit of work
Image format 68021 (64 bit)

Virtual Machine
---------------
C:\Squeak\VMs\Squeak64\Squeak64.exe
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
Win32 built on Mar  3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
Clang 8.0.1 (tags/RELEASE_801/final)
platform sources revision VM: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-nice.2715 uuid:
78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020

Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
<[hidden email]>:

>
> Hi all,
>
> I just updated my Squeak trunk image. After saving, I cannot reload it:
>
> ---------------------------
> Squeak!
> ---------------------------
> Aborting!!!!
> Color depth 0 not supported
> ---------------------------
> OK
> ---------------------------
>
> Then it prints the stack trace and exits.
>
> I restored a backup from yesterday and reloaded my own changes. An
> image saved from that is still functional. After updating Squeak
> again, I see the same error as above, so it is reproducible.
>
> But I cannot invoke the error with a fresh image... so it must be
> something with my image after all. Any ideas or suggestions? Does
> anyone else experience issues after an update?
>
> Kind regards,
> Jakob

Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
The failure is introduced when I load Graphics-mt.432.

More specifically, I see these changes:
DisplayScreen class>>shutDown (removed)
DisplayScreen class>>startUp (removed)
DisplayScreen>>restore (changed)
DisplayScreen>>shrink
DisplayScreen>>shutDown (removed)
Graphics package postscript (changed)

It fails after I load either of these:
DisplayScreen class>>startUp (removed)
Graphics package postscript (changed)

The rest of the changes I can load without breaking the image.

Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
<[hidden email]>:

>
> This is from the image before the update, the VM is the same (should
> be the 5.3 release VM if I remember correctly):
>
> Image
> -----
> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
> Squeak6.0alpha
> latest update: #19634
> Current Change Set: Git unit of work
> Image format 68021 (64 bit)
>
> Virtual Machine
> ---------------
> C:\Squeak\VMs\Squeak64\Squeak64.exe
> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
> Win32 built on Mar  3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
> Clang 8.0.1 (tags/RELEASE_801/final)
> platform sources revision VM: 202003021730
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> CoInterpreter VMMaker.oscog-nice.2715 uuid:
> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020
> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
> e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020
>
> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
> <[hidden email]>:
> >
> > Hi all,
> >
> > I just updated my Squeak trunk image. After saving, I cannot reload it:
> >
> > ---------------------------
> > Squeak!
> > ---------------------------
> > Aborting!!!!
> > Color depth 0 not supported
> > ---------------------------
> > OK
> > ---------------------------
> >
> > Then it prints the stack trace and exits.
> >
> > I restored a backup from yesterday and reloaded my own changes. An
> > image saved from that is still functional. After updating Squeak
> > again, I see the same error as above, so it is reproducible.
> >
> > But I cannot invoke the error with a fresh image... so it must be
> > something with my image after all. Any ideas or suggestions? Does
> > anyone else experience issues after an update?
> >
> > Kind regards,
> > Jakob

Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Levente Uzonyi
I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> <[hidden email]>:
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar  3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar  3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar  3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> <[hidden email]>:
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob

Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

marcel.taeumel
Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob


Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

marcel.taeumel
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob


Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

marcel.taeumel
Hi Christoph.

So it looks as if the whole startup machinery missed to set a display screen depth.

Again, nobody sets the display depth to 0 on shutdown. It usually stays put. As you left it. So it must be some interference with another part ... is still suspect #hibernation. But this bug is hard to reproduce...

>Any idea of how to rescue our images?

Again, try a start-up script. See my previous answer.

Best,
Marcel

Am 06.06.2020 16:09:04 schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob


Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede

Hi Marcel,


thanks for your answer.


Again, try a start-up script. See my previous answer.


I spent the last few hours trying to do that. Can you tell me what's wrong with this?

 > cat .\fix-display.cs
 Display newDepth: 32.
 Smalltalk snapshot: true andQuit: true.
 > &"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\ChristophTrunk.image '.\fix-display.cs'
 Aborting!!!!
 Color depth 0 not supported
 
 Smalltalk stack dump:
           0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
           0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
           0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
           0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
           0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
           0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
           0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
           0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
           0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
           0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
           0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
           0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
           0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
           0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
         0x3f3725c8 s WorldState>doOneCycleFor:
         0x3f3726a0 s PasteUpMorph>doOneCycle
         0x3d5bc998 s [] in MorphicProject>spawnNewProcess
         0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess
Using my non-defect image instead, it works:

```powershell
> &"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\FreshTrunk\FreshTrunk.image '..\fix-display.cs'
> echo $?
True
```

(By the way, I noted that the headless flag is ignored for me, in both calls. Is this a bug?)

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Samstag, 6. Juni 2020 16:20:02
An: squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
Hi Christoph.

So it looks as if the whole startup machinery missed to set a display screen depth.

Again, nobody sets the display depth to 0 on shutdown. It usually stays put. As you left it. So it must be some interference with another part ... is still suspect #hibernation. But this bug is hard to reproduce...

>Any idea of how to rescue our images?

Again, try a start-up script. See my previous answer.

Best,
Marcel

Am 06.06.2020 16:09:04 schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob


Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
In reply to this post by Christoph Thiede
Fabio told me that he could open my image after loading the changes I mentioned. He used a Mac OSX VM from 2019.

I wanted to bisect which VMs work, but when I used the same VM that I currently use from another folder, it suddenly opened my image successfully! The .exe files are equal (only I had renamed the "bad" one to Squeak64.exe for ages).

Now when I rename my sources file, which resides next to the VM, from SqueakV50.sources to SqueakV50.sources_, the image opens. Conversely, if I copy the unrenamed sources file from the "bad" folder to the "good" folder, the "good" VM also produces the error.

Any idea how the sources file might be related to this? By the way, the sources file is an old one, 2017-10-28T20:53.

(Moreover, I found that the very latest VM from bintray 202006010135 does not open any image. I get the open file prompt, but nothing happens afterwards.)

Am Sa., 6. Juni 2020 um 16:09 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob



Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
Downloaded the newest 5.0 sources from squeak.org, but the files are equal, no improvement.

[hidden email] Which sources file are you using?

Am Sa., 6. Juni 2020 um 17:07 Uhr schrieb Jakob Reschke <[hidden email]>:
Fabio told me that he could open my image after loading the changes I mentioned. He used a Mac OSX VM from 2019.

I wanted to bisect which VMs work, but when I used the same VM that I currently use from another folder, it suddenly opened my image successfully! The .exe files are equal (only I had renamed the "bad" one to Squeak64.exe for ages).

Now when I rename my sources file, which resides next to the VM, from SqueakV50.sources to SqueakV50.sources_, the image opens. Conversely, if I copy the unrenamed sources file from the "bad" folder to the "good" folder, the "good" VM also produces the error.

Any idea how the sources file might be related to this? By the way, the sources file is an old one, 2017-10-28T20:53.

(Moreover, I found that the very latest VM from bintray 202006010135 does not open any image. I get the open file prompt, but nothing happens afterwards.)

Am Sa., 6. Juni 2020 um 16:09 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob



Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede
In reply to this post by Jakob Reschke

Now when I rename my sources file, which resides next to the VM, from SqueakV50.sources to SqueakV50.sources_, the image opens. Conversely, if I copy the unrenamed sources file from the "bad" folder to the "good" folder, the "good" VM also produces the error.


Wow, this is great! I did not even need to exchange my executable, but moving the sources file, reverting Graphics-mt.432 manually, and saving the image repaired it again! Afterwards I could rename the sources file back and my image works like a charm now. How did you hit on that?

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:07:07
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Fabio told me that he could open my image after loading the changes I mentioned. He used a Mac OSX VM from 2019.

I wanted to bisect which VMs work, but when I used the same VM that I currently use from another folder, it suddenly opened my image successfully! The .exe files are equal (only I had renamed the "bad" one to Squeak64.exe for ages).

Now when I rename my sources file, which resides next to the VM, from SqueakV50.sources to SqueakV50.sources_, the image opens. Conversely, if I copy the unrenamed sources file from the "bad" folder to the "good" folder, the "good" VM also produces the error.

Any idea how the sources file might be related to this? By the way, the sources file is an old one, 2017-10-28T20:53.

(Moreover, I found that the very latest VM from bintray 202006010135 does not open any image. I get the open file prompt, but nothing happens afterwards.)

Am Sa., 6. Juni 2020 um 16:09 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
In reply to this post by Jakob Reschke
The image also starts if I make the sources file empty, but not if I put a single character in it. If the file is empty, Squeak also shows the prompt that the sources file was not found.

Am Sa., 6. Juni 2020 um 17:13 Uhr schrieb Jakob Reschke <[hidden email]>:
Downloaded the newest 5.0 sources from squeak.org, but the files are equal, no improvement.

[hidden email] Which sources file are you using?

Am Sa., 6. Juni 2020 um 17:07 Uhr schrieb Jakob Reschke <[hidden email]>:
Fabio told me that he could open my image after loading the changes I mentioned. He used a Mac OSX VM from 2019.

I wanted to bisect which VMs work, but when I used the same VM that I currently use from another folder, it suddenly opened my image successfully! The .exe files are equal (only I had renamed the "bad" one to Squeak64.exe for ages).

Now when I rename my sources file, which resides next to the VM, from SqueakV50.sources to SqueakV50.sources_, the image opens. Conversely, if I copy the unrenamed sources file from the "bad" folder to the "good" folder, the "good" VM also produces the error.

Any idea how the sources file might be related to this? By the way, the sources file is an old one, 2017-10-28T20:53.

(Moreover, I found that the very latest VM from bintray 202006010135 does not open any image. I get the open file prompt, but nothing happens afterwards.)

Am Sa., 6. Juni 2020 um 16:09 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi all,


exactly the same issue here. Using SqueakConsole.exe (Windows) gave me the following stack trace:


Aborting!!!!
Color depth 0 not supported

Smalltalk stack dump:
          0xa75640 I DisplayScreen>forceToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75678 M [] in DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa756b8 M OrderedCollection>do: 0x6208b90: a(n) OrderedCollection
          0xa75710 I DisplayScreen>forceDamageToScreen: 0x26cb5ef0: a(n) DisplayScreen
          0xa75758 I WorldState>forceDamageToScreen: 0x6b84020: a(n) WorldState
          0xa757e0 I WorldState>displayWorld:submorphs: 0x6b84020: a(n) WorldState
          0xa75830 I PasteUpMorph>privateOuterDisplayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa75870 I PasteUpMorph>displayWorld 0x1b5f50e8: a(n) PasteUpMorph
          0xa758a8 M [] in WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa758e8 M [] in WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState
          0xa75920 M FullBlockClosure(BlockClosure)>on:do: 0x5f7cff0: a(n) FullBlockClosure
          0xa75980 I WorldState>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: 0x6b84020: a(n) WorldState // this is from Morphic-ct.1638 (inbox), but it only affects the opening of debuggers
          0xa759e8 I WorldState>displayWorldSafely: 0x6b84020: a(n) WorldState
          0xa75a38 I WorldState>doOneCycleNowFor: 0x6b84020: a(n) WorldState
        0x3f3725c8 s WorldState>doOneCycleFor:
        0x3f3726a0 s PasteUpMorph>doOneCycle
        0x3d5bc998 s [] in MorphicProject>spawnNewProcess
        0x3ceb3ae0 s [] in FullBlockClosure(BlockClosure)>newProcess

So it looks as if the whole startup machinery missed to set a display screen depth.

Interestingly, a second image updated which I use for the sole purpose of installing the latest updates, currently on #19705, is not affected and can be restarted.

Any idea of how to rescue our images? I saved mine dozens of times since I restarted the VM the last time after installing the latest Trunk updates. The error only occurs after restarting your VM.


At all folks, better don't shutdown your image until this has been fixed or it will never awake again! ūüėď


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Mai 2020 10:13 Uhr
An: Levente Uzonyi; squeak-dev
Betreff: Re: [squeak-dev] Image not startable after save
 
... maybe Form >> #hibernate (via Form class >> #shutDown) is interfering with "depth" in some situations on some platforms? In any case, it does not seem a good idea to #hibernate the DisplayForm ... because #unhibernate is an in-image mechanism, while the "bits" of the DisplayForm are known to the VM (plugins) after #beDisplay.

Best,
Marcel

Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <[hidden email]>:

Hi, there.

Hmm... I think that the position of Project in the StartUpList and ShutDownList is unrelated to this issue. I think I just removed a duplication via Graphics-mt.432.

Looking at Display >> #restore, the bug Jakob mentioned could be related to an issue with "depth" being "0" in the Display object. Not sure how this can happen in any image unless maybe some class-recompilation hickup? But then "nil" would be more likely a reset value than "0" .... 

Anyway, since "AutoStart" is before "Project" in the start-up list, you can start the VM + image + startup script to then reset "depth" in "Display" to "32". :-)

Display newDepth: 32

Best,
Marcel

Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <[hidden email]>:

I haven't tried to reproduce it yet, but I think the cause of the problem
is that Project - where the new start up code is - is the 41st on the
StartUpList, while DisplayScreen was the 4th.
It is possible that objects between those two indexes assume that the
Display had been set up correctly when their #startUp: method is sent.

Also, I just went through the StartUpList and I found that it includes
classes which do not override #startUp or #startUp:, so their existence on
the list is questionable.

There are also plenty of classes which implement #startUp instead of
#startUp:, which is a problem because #startUp should be deprecated and
removed.

Very likely there are similar issues with the ShutDownList.


Levente

On Sun, 24 May 2020, Jakob Reschke wrote:

> The failure is introduced when I load Graphics-mt.432.
>
> More specifically, I see these changes:
> DisplayScreen class>>shutDown (removed)
> DisplayScreen class>>startUp (removed)
> DisplayScreen>>restore (changed)
> DisplayScreen>>shrink
> DisplayScreen>>shutDown (removed)
> Graphics package postscript (changed)
>
> It fails after I load either of these:
> DisplayScreen class>>startUp (removed)
> Graphics package postscript (changed)
>
> The rest of the changes I can load without breaking the image.
>
> Am Fr., 22. Mai 2020 um 18:36 Uhr schrieb Jakob Reschke
> :
>>
>> This is from the image before the update, the VM is the same (should
>> be the 5.3 release VM if I remember correctly):
>>
>> Image
>> -----
>> C:\Users\Jakob\HiDrive\Squot-trunk-64bit.2.image
>> Squeak6.0alpha
>> latest update: #19634
>> Current Change Set: Git unit of work
>> Image format 68021 (64 bit)
>>
>> Virtual Machine
>> ---------------
>> C:\Squeak\VMs\Squeak64\Squeak64.exe
>> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-nice.2715]
>> Win32 built on Mar 3 2020 08:36:19 GMT Compiler: 4.2.1 Compatible
>> Clang 8.0.1 (tags/RELEASE_801/final)
>> platform sources revision VM: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
>> 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> CoInterpreter VMMaker.oscog-nice.2715 uuid:
>> 78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
>> StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
>> e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
>>
>> Am Fr., 22. Mai 2020 um 18:33 Uhr schrieb Jakob Reschke
>> :
>> >
>> > Hi all,
>> >
>> > I just updated my Squeak trunk image. After saving, I cannot reload it:
>> >
>> > ---------------------------
>> > Squeak!
>> > ---------------------------
>> > Aborting!!!!
>> > Color depth 0 not supported
>> > ---------------------------
>> > OK
>> > ---------------------------
>> >
>> > Then it prints the stack trace and exits.
>> >
>> > I restored a backup from yesterday and reloaded my own changes. An
>> > image saved from that is still functional. After updating Squeak
>> > again, I see the same error as above, so it is reproducible.
>> >
>> > But I cannot invoke the error with a fresh image... so it must be
>> > something with my image after all. Any ideas or suggestions? Does
>> > anyone else experience issues after an update?
>> >
>> > Kind regards,
>> > Jakob



Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Jakob Reschke
In reply to this post by Christoph Thiede
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.



Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

fniephaus


On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.




Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede
In reply to this post by Christoph Thiede

Could there be some cache of a previous sources file version that is overriding the #startUp method saved in the image?


At the moment, my workaround to keep using my image is:

  1. Move sources file away
  2. Start image
  3. Move sources file back
  4. In the "Cannot locate sources file" warning, debug invocation
  5. Restart from the FileDirectory class >> #openSources:andChanges:forImage: context.


You can use the sources file and save your image as usually, but you will need to repeat the above steps upon every image restart ...

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Samstag, 6. Juni 2020 17:43 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

Christoph Thiede
In reply to this post by fniephaus

I just got it! It was indeed a question of load order. After moving #DisplayScreen in the StartUpList back to index 5 (instead of appending it at the end), my image starts again without renaming any files.

I suppose that all these renamings tricks were only relevant for deferring the execution of the startup list, which - so I suspect - reset the display screen depth temporarily at some point, I don't know.


So to summarize, to rescue your image, you have to:

  • apply the 5 steps from my previous message once
  • add DisplayScreen >> #startUp (*)
  • Evaluate this:
    (SmalltalkImage classVarNamed: #StartUpList) add: #DisplayScreen afterIndex: 4
  • And save your image.


I hope this helps other people to rescue their images, too :-)


* Source:

startUp  "DisplayScreen startUp"
Display setExtent: self actualScreenSize depth: Display nativeDepth.
Display beDisplay

Nevertheless thank you for the kind offer, Fabio!


Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:54:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 


On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.




Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

marcel.taeumel
Hi all!

DisplayScreen should be removed from the startup list. It is not necessary anymore. Project will do the job just fine.

Yeah, the trick I suggested with the start-up script will -- unfortunately -- not work. ProjectLauncher is processing those after the first drawing cycle in Morphic.

Those cases with a broken display depth in some images out there still puzzles me. Given that the .sources-file-not-found trick works, there is something else in the StartUpList after 8 (FileDirectory) that actually breaks the Display object, which means that it works up to that point. Note that 8 > 5. ;-) Everything *can* work without having DisplayScreen in the StartUpList.

Your broken images are really valuable here! Please do not overwrite them.

Best,
Marcel

Am 06.06.2020 18:17:35 schrieb Thiede, Christoph <[hidden email]>:

I just got it! It was indeed a question of load order. After moving #DisplayScreen in the StartUpList back to index 5 (instead of appending it at the end), my image starts again without renaming any files.

I suppose that all these renamings tricks were only relevant for deferring the execution of the startup list, which - so I suspect - reset the display screen depth temporarily at some point, I don't know.


So to summarize, to rescue your image, you have to:

  • apply the 5 steps from my previous message once
  • add DisplayScreen >> #startUp (*)
  • Evaluate this:
    (SmalltalkImage classVarNamed: #StartUpList) add: #DisplayScreen afterIndex: 4
  • And save your image.


I hope this helps other people to rescue their images, too :-)


* Source:

startUp  "DisplayScreen startUp"
Display setExtent: self actualScreenSize depth: Display nativeDepth.
Display beDisplay

Nevertheless thank you for the kind offer, Fabio!


Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:54:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 


On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.




Reply | Threaded
Open this post in threaded view
|

Re: Image not startable after save

marcel.taeumel
Here are things you might also try when having that sources-file-not-found situation in your broken image:

- Change DisplayScreen >> #restore to use "32" instead of "self nativeDepth"
- Move Project up in the StartUpList
- Change DisplayScreen >> #restore to not send #displaySizeChanged
- Verify that "Form allSubInstances count: [:form | form depth = 0]" answers 0
- Log all calls to DisplayScreen >> #setExtent:depth:
- Just save-as-new the image and try to start that again

Best,
Marcel 

Am 07.06.2020 11:48:27 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

DisplayScreen should be removed from the startup list. It is not necessary anymore. Project will do the job just fine.

Yeah, the trick I suggested with the start-up script will -- unfortunately -- not work. ProjectLauncher is processing those after the first drawing cycle in Morphic.

Those cases with a broken display depth in some images out there still puzzles me. Given that the .sources-file-not-found trick works, there is something else in the StartUpList after 8 (FileDirectory) that actually breaks the Display object, which means that it works up to that point. Note that 8 > 5. ;-) Everything *can* work without having DisplayScreen in the StartUpList.

Your broken images are really valuable here! Please do not overwrite them.

Best,
Marcel

Am 06.06.2020 18:17:35 schrieb Thiede, Christoph <[hidden email]>:

I just got it! It was indeed a question of load order. After moving #DisplayScreen in the StartUpList back to index 5 (instead of appending it at the end), my image starts again without renaming any files.

I suppose that all these renamings tricks were only relevant for deferring the execution of the startup list, which - so I suspect - reset the display screen depth temporarily at some point, I don't know.


So to summarize, to rescue your image, you have to:

  • apply the 5 steps from my previous message once
  • add DisplayScreen >> #startUp (*)
  • Evaluate this:
    (SmalltalkImage classVarNamed: #StartUpList) add: #DisplayScreen afterIndex: 4
  • And save your image.


I hope this helps other people to rescue their images, too :-)


* Source:

startUp  "DisplayScreen startUp"
Display setExtent: self actualScreenSize depth: Display nativeDepth.
Display beDisplay

Nevertheless thank you for the kind offer, Fabio!


Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:54:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 


On Sat, 6 Jun 2020 at 5:43 pm, Thiede, Christoph <[hidden email]> wrote:

Thank you, Jakob.


Well, I have to revoke my previous success message. Restarting my image another time and it crashes again on startup ...


But I have looked up my sources files. They do contain DisplayScreen class >> #startUp. And (Smalltalk class classVarNamed: #StartUpList) includes: #DisplayScreen. What could be the problem?

Wild guess: there's something wrong with the display form and the Windows VM crashes before the beDisplay primitive is called with a fresh one. That could explain why it works on macOS. I could have a look at the raw display object if you provide an image.

Fabio


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 17:33:16

An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Image not startable after save
 
Am Sa., 6. Juni 2020 um 17:25 Uhr schrieb Thiede, Christoph <[hidden email]>:

How did you hit on that?

 
That I tried the same copy of the VM from another folder at all is because I have the unpacked zips lying around and always copy the current VM that I use to a different folder, where the Windows file association looks for it. So when I switch VMs, I won't have to tell Windows again how to open these .image files...

I compared the folders with a merge tool (after renaming my Squeak64.exe .ini and .manifest back). All the binary files are equal, and Monticello/Metacello cache folders, the default image and changes file, debug logs, and crash dumps aside, the only meaningful difference left was eventually the presence of the sources file.




12