[squeak-dev] Image not startable after save

Jakob Reschke forums.jakob at resfarm.de
Sun Jun 7 11:39:09 UTC 2020


After updating the "broken" image without the sources file with your
latest trunk submissions, I can save the image, restore the sources
file, and reopen the image successfully. Thank you very much!

Am So., 7. Juni 2020 um 12:44 Uhr 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?
>
>
> Best,
> Marcel
>
> 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.
>
> Best,
> Marcel
>
> 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> 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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <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>:
>>>
>>> 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.
>>
>>
>



More information about the Squeak-dev mailing list