Smalltalk › Pharo › Pharo Smalltalk Users

Pharo70 session start and silent failures

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Holger Freyther

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

Sean P. DeNigris

Re: Pharo70 session start and silent failures

Administrator

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

Cheers,
Sean

Denis Kudriashov

Re: Pharo70 session start and silent failures

In reply to this post by Holger Freyther

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 <[hidden email]>:

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

Guillermo Polito

Re: Pharo70 session start and silent failures

In reply to this post by Holger Freyther

On Thu, May 3, 2018 at 3:13 PM, Holger Freyther <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Holger Freyther

Re: Pharo70 session start and silent failures

> On 14. May 2018, at 17:39, Guillermo Polito <[hidden email]> 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.

Guillermo Polito

Re: Pharo70 session start and silent failures

Thanks, I'll open an issue and check it.

On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <[hidden email]> wrote:

> On 14. May 2018, at 17:39, Guillermo Polito <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Guillermo Polito

Re: Pharo70 session start and silent failures

https://pharo.fogbugz.com/f/cases/21907/Freezes-on-startup

On Tue, May 15, 2018 at 9:29 AM, Guillermo Polito <[hidden email]> wrote:

Thanks, I'll open an issue and check it.

On Tue, May 15, 2018 at 8:35 AM, Holger Freyther <[hidden email]> wrote:

> On 14. May 2018, at 17:39, Guillermo Polito <[hidden email]> 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

Web: 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13