[squeak-dev] Image not startable after save

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Jun 6 15:24:45 UTC 2020

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


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
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 <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>>:

Hi all,

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

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



Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> 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.


Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <marcel.taeumel at hpi.de<mailto:marcel.taeumel at hpi.de>>:

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


Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <leves at caesar.elte.hu<mailto:leves at caesar.elte.hu>>:

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

Very likely there are similar issues with the ShutDownList.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200606/3b6c18db/attachment-0001.html>

More information about the Squeak-dev mailing list