Posted by
Ben Coman on
Jul 26, 2018; 11:06am
URL: https://forum.world.st/Pharo7-consistent-image-freeze-deadlock-on-snapshotAndQuit-tp5082114p5082173.html
I don't have a total answer, but can confirm the problem and help
characterize it.
First, great test-snippet. Really nice and concise.
On Windows it indeed freezes my Pharo 7 image when saving the image.
It doesn't freeze Pharo 6.
It doesn't freeze if the test-processes are not terminated.
It doesn't freeze if the shutdown code runs at a lower priority that
the test-processes.
i.e. it works with these added lines...
shutDown: quitting
"+" |restorePriority|
"+" restorePriority := Processor activeProcess priority.
"+" Processor activeProcess priority: 15.
Process1 ifNotNil:[ Process1 terminate ].
Process2 ifNotNil: [Process2 terminate ].
"+" Processor activeProcess priority: restorePriority.
Process1 := Process2 := nil
Does that help someone else identify the relevant changes between Pharo 6 & 7
to explain the behaviour in more depth.
cheers -ben
On 26 July 2018 at 00:46, Johan Brichau <
[hidden email]> wrote:
> Hi,
>
> I ran into a freeze issue when trying to save and/or quit an image after loading Seaside3 and Zinc (not an infrequent combination :)
>
> The cause seems to be that terminating processes in a `shutDown` handler (called on image shutdown / snapshot) leads to a deadlock (somewhere).
> Both Comet and Zinc will send #terminate to a process when an image is quit or saved. If I disable one of those, the deadlock does not occur.
>
> I managed to reconstruct the issue with a simple example, attached.
>
> The attached Freeze class creates two processes (that loop with a Delay>>wait inside) in the `startUp` method (on image start).
> These processes are terminated by the shutdown method (called on image quit/save).
> However, when you try to quit and/or save the image, you will experience an image freeze.
>
> I’m not familiar with the process scheduler, or anything else in this context… so help would be appreciated while I try to dive further into it :)
>
> To reproduce: just file in the attached file in a Pharo7 image and try to quit.
> For reference, System Reporter output for my configuration.
>
> Any ideas?
>
> Cheers
> Johan
>
>
>
>
> Image
> -----
> /Users/jbrichau/Pharo/images/Pharo 7.0 - 64bit (development version)/Pharo 7.0 - 64bit (development version).image
> Pharo7.0alpha
> Build information: Pharo-7.0+alpha.build.1131.sha.a46bfaef44ba209888c92fa0e3bd3a5e04a38c5d (64 Bit)
> Unnamed
>
> Virtual Machine
> ---------------
> /Users/jbrichau/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo
> CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
> StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
> VM: 201806281256
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256
https://github.com/OpenSmalltalk/opensmalltalk-vm.git>
> Mac OS X built on Jun 28 2018 13:07:33 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)
> VMMaker versionString VM: 201806281256
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256
https://github.com/OpenSmalltalk/opensmalltalk-vm.git> CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
> StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
>
>