[squeak-dev] Image not startable after save

Marcel Taeumel marcel.taeumel at hpi.de
Sun Jun 7 11:30:22 UTC 2020

... an afterthought: I always suspected that the "0" was wrongfully supplied from the image to the VM. Especially since that bug occurred rather rarely, which usually points to the variety of images users usually have. :-)

Am 07.06.2020 12:43:52 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi all!

I found the bug. I think. :-)

1. The Solution:

- Move Project before AutoStart in the StartUpList --- maybe even before PasteUpMorph and ControlManager bc. Project is more general than those two, which should be removed alltogether from the list
- In PasteUpMorph >> #installFlaps, replace "self displayWorld" with "self changed"
- From AutoStart class >> #startUp:, move "Project current startUpActions" to Project class >> #startUp:

Doing either one of those will fix the bug. But all are quite important in the long term. ;-)

2. The Bug:

AutoStart has a weird call to Project class >> #startUpActions. If you happen to have local flap tabs (not just the shared/global ones), those actions will trigger a #displayWorld, which will then try to force display updates. At that point, the VM has no idea about the actual display depth and defaults to 0 --- while the image still has 32 configured for the display object.

We did not notice this because DisplayScreen did set those values way before AutoStart was called.

3. How did I found out?

By looking at the complete stack trace. AutoStart was in there. Then it was easy to see and spot in the actual source code.

          0xa6e4a0 I DisplayScreen>forceToScreen: 0x5d2cb78: a(n) DisplayScreen
          0xa6e4d8 M [] in DisplayScreen>forceDamageToScreen: 0x5d2cb78: a(n) DisplayScreen
          0xa6e518 M OrderedCollection>do: 0x5810168: a(n) OrderedCollection
          0xa6e570 I DisplayScreen>forceDamageToScreen: 0x5d2cb78: a(n) DisplayScreen
          0xa6e5b8 I AnimWorldState(WorldState)>forceDamageToScreen: 0xb33abd0: a(n) AnimWorldState
          0xa6e628 I AnimWorldState(WorldState)>displayWorld:submorphs: 0xb33abd0: a(n) AnimWorldState
          0xa6e678 I PasteUpMorph>privateOuterDisplayWorld 0xb33a7f8: a(n) PasteUpMorph
  !!!     0xa6e6b8 I PasteUpMorph>displayWorld 0xb33a7f8: a(n) PasteUpMorph
  !!!     0xa6e6f8 I [] in PasteUpMorph>installFlaps 0xb33a7f8: a(n) PasteUpMorph
          0xa6e758 I OrderedCollection(SequenceableCollection)>keysAndValuesDo: 0x5687588: a(n) OrderedCollection
          0xa6e7a8 I PasteUpMorph>installFlaps 0xb33a7f8: a(n) PasteUpMorph
          0xa6e7e8 I PasteUpMorph>install 0xb33a7f8: a(n) PasteUpMorph
  !!!     0xa6e828 I AnimMorphicProject(MorphicProject)>startUpActions 0xb33a718: a(n) AnimMorphicProject
          0xa6e878 I AutoStart class>startUp: 0x60a6db0: a(n) AutoStart class

@Christoph: I cannot relate to the stack trace you posted here earlier. It seems way too late for the bug to show itself. Can you post it again?

Am 07.06.2020 11:48:27 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
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.

Am 06.06.2020 18:17:35 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Fabio Niephaus <lists at fniephaus.com>
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 <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]> 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.


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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200607/056365e7/attachment.html>

More information about the Squeak-dev mailing list