Pharo70 session start and silent failures
I am facing a problem with the new SessionManager>>#snapshot:andQuit: code. I have had plenty Pharo70 images that didn't restore anymore as the code is waiting for the "wait" semaphore. For sure it is something my code is doing but could anyone think of ways to make it more robust and handle failures more gracefully? My main concerns are: * When the failure becomes noticeable it is too late. :( * It fails silently. Maybe WorkingSession>>#runStartup: shouldn't rely on the UIManager doing the right thing (before the UI was fully initialized?) * Debugging is hard, there is no indication of why it broke, and getting to the situation of breakage takes a bit of time (installing the baseline..). holger
Holger Freyther wrote
I have had plenty Pharo70 images that didn't restore anymoreâ¦
+1. I think it has been related to errors in my startup code e.g. classes renamed/removed since 6.1, but not sure. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I had similar problem with SSDP server. When I tried to stop it during shutdown of image the image didn't closed. It hangs forever. In some cases I was able to open debugger which pointed to exactly same place which you mentioned. My guess was that process termination during shutdown is not safe anymore. But I had no time to check deeply. 2018-05-03 16:13 GMT+03:00 Holger Freyther <holger@freyther.de>:
I am facing a problem with the new SessionManager>>#snapshot:andQuit: code. I have had plenty Pharo70 images that didn't restore anymore as the code is waiting for the "wait" semaphore. For sure it is something my code is doing but could anyone think of ways to make it more robust and handle failures more gracefully? My main concerns are:
* When the failure becomes noticeable it is too late. :( * It fails silently. Maybe WorkingSession>>#runStartup: shouldn't rely on the UIManager doing the right thing (before the UI was fully initialized?) * Debugging is hard, there is no indication of why it broke, and getting to the situation of breakage takes a bit of time (installing the baseline..).
holger
On Thu, May 3, 2018 at 3:13 PM, Holger Freyther <holger@freyther.de> wrote:
I am facing a problem with the new SessionManager>>#snapshot:andQuit: code. I have had plenty Pharo70 images that didn't restore anymore as the code is waiting for the "wait" semaphore. For sure it is something my code is doing but could anyone think of ways to make it more robust and handle failures more gracefully? My main concerns are:
* When the failure becomes noticeable it is too late. :( * It fails silently. Maybe WorkingSession>>#runStartup: shouldn't rely on the UIManager doing the right thing (before the UI was fully initialized?) * Debugging is hard, there is no indication of why it broke, and getting to the situation of breakage takes a bit of time (installing the baseline..).
Can you give me more details about how to reproduce it? You're loading a baseline as a startup action? As a startup script?
holger
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito@gmail.com> wrote:
Can you give me more details about how to reproduce it?
1.) Load MCZ into image (ignore the missing dependency) http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore-HolgerHansPeterFreythe... 2.) Save image => Image is now "frozen" (with "save and quit" it would be broken for good)
You're loading a baseline as a startup action? As a startup script?
I start and stop processes and Denis has pointed out to have had issues with it as well.
Thanks, I'll open an issue and check it. On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <holger@freyther.de> wrote:
On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito@gmail.com> wrote:
Can you give me more details about how to reproduce it?
1.) Load MCZ into image (ignore the missing dependency)
http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore- HolgerHansPeterFreyther.43.mcz
2.) Save image
=> Image is now "frozen" (with "save and quit" it would be broken for good)
You're loading a baseline as a startup action? As a startup script?
I start and stop processes and Denis has pointed out to have had issues with it as well.
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
https://pharo.fogbugz.com/f/cases/21907/Freezes-on-startup On Tue, May 15, 2018 at 9:29 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
Thanks, I'll open an issue and check it.
On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <holger@freyther.de> wrote:
On 14. May 2018, at 17:39, Guillermo Polito <guillermopolito@gmail.com> wrote:
Can you give me more details about how to reproduce it?
1.) Load MCZ into image (ignore the missing dependency)
http://smalltalkhub.com/mc/osmocom/Core/main/OsmoCore-Holger HansPeterFreyther.43.mcz
2.) Save image
=> Image is now "frozen" (with "save and quit" it would be broken for good)
You're loading a baseline as a startup action? As a startup script?
I start and stop processes and Denis has pointed out to have had issues with it as well.
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
participants (4)
-
Denis Kudriashov -
Guillermo Polito -
Holger Freyther -
Sean P. DeNigris