- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

On Wed, May 18, 2016 at 9:49 PM, Martin McClure <martin(a)hand2mouse.com> wrote: > On 05/18/2016 03:17 PM, Martin McClure wrote: > >> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote: >> >>> Hi guys, >>> >>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot >>> explain how this could happened but it does, and it happened to me a couple >>> of times (but not fully reproducible). >>> >>> >> Hmm. The schedulerResumptionTime is, somehow, being (approximately) >> doubled. It's not clear how that can happen, but I'll look a little more. >> >> > Mario, is there any chance that you might be saving the image during one > of these Delays? > > > This one smells like a race condition, and I think I see something that > *might* explain it. But I don't have any more time to spend on this one, so > I'll leave the rest to someone else. I hope this is helpful: > > The only way I immediately see for the schedulerResumptionTime to become > approximately doubled is if the Delay's resumption time is adjusted by > #restoreResumptionTimes without previously having been adjusted by > #saveResumptionTimes. > > The only time either of those are sent, that I can see, is on saving the > image. Both are normally sent, (save before the snapshot, restore > afterwards), but there may be a hole there. > > Martin, first off, thanks for the research!!! Now....your email made me remember something:* I did get VM crash when saving the image a couple of times. The VM crashed when saving the image. *If I re-opened the image, it looks like if the image was indeed saved (so the snapshot primitive itself did work), but I suspect not all shutdown code could have been run correctly. The VM crash looks like the FreeTypeFace >> pvtDestroyHandle which, as far as I know, it's a "known crash" (I attach crash dump). From what I can see, if I follow all the stack, the crash starts from the WeakArray >> startUp: . That means that...depending on the order of the startup list...the Scheduler may not have been run after the crash. Now.... WeakArray initialization does: SessionManager default registerSystemClassNamed: self name. While... Delay class >> startUp "Restart active delay, if any, when resuming a snapshot." Scheduler startUp. And the Delay registration is SessionManager default registerSystemClassNamed: self name atPriority: 20. So...that seems correct... I can verify this by: SessionManager default systemCategory prioritizedList Anyway...not sure if this adds something, but just wanted to note this. > #saveResumptionTimes is only sent (by this scheduler class) when the > accessProtect semaphore is held, but #handleTimerEvent: is executed in the > timing Process *without* the protection of accessProtect, in the case of > the VM signaling the timingSemaphore. If the VM signals the > timingSemaphore, #handleTimerEvent: could run in the middle of > #saveResumptionTimes. If some Delay expires because of that timer event, > our Delay could move from being the first suspended delay to being the > active delay. If that happens after we've adjusted the active delay, but > before we've processed the suspended delays, that Delay will not get > adjusted, and will show the symptoms that Mariano is seeing. > > Also, I'm not sure how the Heap that holds the suspendedDelays will react > to being modified in the middle of an enumeration. That might open a larger > window for the problem. > > Regards, > > -Martin > > -- Mariano http://marianopeck.wordpress.com

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Sven Van Caekenberghe

Actually the problem is even worse, NetNameResolver class>>#addressForName: not just hangs for at least its timeout period, during that time the whole image seems to be blocked (as it is a primitive). That is why this is so annoying (spotter goes to great length to work in a background thread, but that does not seem to help here). > On 19 May 2016, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 19 May 2016, at 13:41, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> This is hyper annoying that Spotter look for the net by default. >> >> We should turn it off. > > This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image. > > The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way. > > This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me. > > That is the issue that we should fix. > > Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century. > > So I vote against turning it off. > >> We should also improve the comment of the catalog setting because it is unclear >> >> that this is this setting that should be turned off. > > Yes that would be good. > >> Stef >> >> >

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Peter UhnÃ¡k

On Thu, May 19, 2016 at 1:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > This situation is also hard to debug, because if I turn off my wireless > network, NetNameResolver fails immediately (which is perfect). It is hard > to reproduce the case where it hangs, at least for me. > What about instead of turning off the network just open and listen on a local port and direct DNS there? And because there will be no response it might hangâ¦ just an ideaâ¦ Peter

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Sven Van Caekenberghe

> On 19 May 2016, at 13:41, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > This is hyper annoying that Spotter look for the net by default. > > We should turn it off. This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image. The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way. This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me. That is the issue that we should fix. Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century. So I vote against turning it off. > We should also improve the comment of the catalog setting because it is unclear > > that this is this setting that should be turned off. Yes that would be good. > Stef > >

May 19, 2016

Turning off Spotter using internet!

by stepharo

Hi guys This is hyper annoying that Spotter look for the net by default. We should turn it off. We should also improve the comment of the catalog setting because it is unclear that this is this setting that should be turned off. Stef

May 19, 2016

Re: [Pharo-dev] [ANN] Pharo Sprint 27 May

by Marcus Denker

> On 19 May 2016, at 12:37, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > what time the sprint ends ? it slows down and drops out around 17-18h local time normally. > is the sprint only bug orientated ? what about adding class and method comments ? The idea is to do boring stuff that you canât get yourself todo normallyâ¦ this is the overall direction, not a strict rule. > I can only attend remotely > Yes, this is why we make it public: so people can join remotely. Of course it is not the same, but it can be fun, too. Marcus > On Thu, May 19, 2016 at 11:56 AM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > We will organize a Pharo sprint / Moose dojo Friday, 27 May, starting at > 10:00am. (Local Time Lille). > > It will be at the Inria Lille, Building B, third floor (RMoD offices). > > Remotely, you can join us on Slack or the IRC channel #pharo on > irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize > local and remote Pharo sprinters. > > As the building is not open to the public, please contact us before if > you plan to come. >

May 19, 2016

Re: [Pharo-dev] [ANN] Pharo Sprint 27 May

by Dimitris Chloupis

what time the sprint ends ? is the sprint only bug orientated ? what about adding class and method comments ? I can only attend remotely On Thu, May 19, 2016 at 11:56 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > We will organize a Pharo sprint / Moose dojo Friday, 27 May, starting at > 10:00am. (Local Time Lille). > > It will be at the Inria Lille, Building B, third floor (RMoD offices). > > Remotely, you can join us on Slack or the IRC channel #pharo on > irc.freenode.net server. During the sprint, we will try to synchronize > local and remote Pharo sprinters. > > As the building is not open to the public, please contact us before if > you plan to come. > >

May 19, 2016

[ANN] Pharo Sprint 27 May

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Friday, 27 May, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on Slack or the IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

May 19, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60020 Home: https://github.com/pharo-project/pharo-core

May 19, 2016

[pharo-project/pharo-core] ea95e4: 60020

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ea95e4aa77ae2c749003d9dae05755f3f3e98d4b https://github.com/pharo-project/pharo-core/commit/ea95e4aa77ae2c749003d9da… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-19 (Thu, 19 May 2016) Changed paths: M OpalCompiler-Core.package/OCClassScope.class/instance/lookup/findVariable_ifNone_.st R OpalCompiler-Core.package/extension/SystemDictionary/instance/findVariable_ifNone_.st A OpalCompiler-Core.package/extension/TClass/instance/findGlobalVariable_ifNone_.st A Polymorph-Widgets.package/extension/GLMTabLabelBrick/instance/themeChanged.st A Rubric.package/extension/TextAction/instance/rubActOnClick_for_in_editor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60019.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60020.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60019.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60020.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60020 18248 TextAction>>rubActOnClick:for:in:editor: missing https://pharo.fogbugz.com/f/cases/18248 18270 add #themeChanged method for GLMTabLabelBrick https://pharo.fogbugz.com/f/cases/18270 18266 OCClassScope should ask class directly to find variable https://pharo.fogbugz.com/f/cases/18266 http://files.pharo.org/image/60/60020.zip

May 19, 2016