[squeak-dev] Image not startable after save

Sat Jun 6 15:07:07 UTC 2020

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

> 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 <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.
>
> Best,
> Marcel
>
> Am 25.05.2020 10:04:06 schrieb Marcel Taeumel <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
>
> Best,
> Marcel
>
> Am 24.05.2020 19:06:57 schrieb Levente Uzonyi <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
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200606/c4c95e51/attachment.html>