[squeak-dev] Image not startable after save

Sat Jun 6 15:25:51 UTC 2020

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 <
forums.jakob at resfarm.de>:

> Downloaded the newest 5.0 sources from squeak.org, but the files are
> equal, no improvement.
>
> @Taeumel, Marcel <Marcel.Taeumel at hpi.de> Which sources file are you using?
>
> Am Sa., 6. Juni 2020 um 17:07 Uhr schrieb Jakob Reschke <
> forums.jakob at resfarm.de>:
>
>> 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/b285f968/attachment.html>