Image not startable after save

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

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

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

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

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

Thank you, Jakob.

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

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.

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.